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SYSTEM AND METHOD FOR ADMINISTERING A FINANCIAL 
PROGRAM INVOLVING THE COLLECTION OF PAYMENTS 

CROSS-REFERENCE TO RELATED APPLICATIONS 

This application claims the benefit of U.S. Provisional Application No. 
60/224,234, filed on August 10, 2000, which is incorporated by reference herein in its 
entirety. 

BACKGROUND OF THE INVENTION 

The present invention generally relates to a system and method for 
5 administering a financial program involving the collection of payments. In a more 
particular embodiment, the present invention relates to a system and method for 
administering an insurance program involving the collection of payments pertaining to 
life insurance policies. 

Financial programs commonly require the processing of a large amount of 
10 information on a periodic basis. A typical insurance program, for instance, involves 
the periodic collection and processing of premium payments from its customers. 
Hence, it is not surprising that the financial fields have traditionally relied heavily on 
the use of computers to automate these tasks. For instance, computer technology has 
been frequently used in the financial fields since at least the 1970's. 

1 5 Many financial programs provide services to customers over an extended 

period of time. For instance, brokerage systems and banking-related systems are 
expected to provide uninterrupted service to their customers for as long as the 
customers choose to receive the services, which may extend over decades. This is 
also particularly true of life insurance programs. A life insurance program is expected 

20 to provide uninterrupted and reliable service to a customer from the issuance of a 

policy to the customer to the policy's termination (e.g., at the customer's death). The 
period of service in this case may extend over a significant portion of the customer's 
life. 
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The relatively long commitment associated with insurance programs may 
result in the use of out-of-date computer equipment to implement the programs. For 
instance, some financial providers may be reticent to makes changes to their existing 
systems due to the perceived difficulty in transferring control from an "old system" 
that interacts with an "old database," to a "new system" that interacts with a "new 
database." Such a transfer must be performed without jeopardizing the integrity of 
stored data, and without interrupting the continuum of services provided to the 
customers. It is not always clear how to make the transition from an old system to a 
new system, while satisfying the above quality-of- service constraints. 

More specifically, as appreciated by the present inventors, it would be 
desirable to convert data obtained from a prior system in a manner that does not 
require continued access to the prior system. This is because the prior system may 
maintain the data using an execution platform that differs from the new system, 
making data transfer problematic. The difficulty in data transfer may further be 
compounded by the fact that such data may be stored in the prior system in multiple 
and/or complexly-structured data files. At the same time, as appreciated by the 
present inventors, it would be desirable to maintain some flexibility in converting data 
from the prior system to the new system. For instance, systems that have been in 
existence for many years may suffer from corrupted data, missing (lost) data, and/or 
corrupted or lost program code. As appreciated by the present inventors, these 
anomalies may render it difficult to transfer data and logic to a new system as a one- 
time effort. Rather, a system designer may find it desirable to change the 
methodology of data conversion as work on the new system proceeds (thus making 
flexibility in data transfer a useful feature). There is no indication in the known prior 
art of how to address these problems. Indeed, there is no indication that others had the 
insight to even articulate the problems in the manner stated above. 

Still other providers may be unwilling to make changes to their systems 
because of insufficient interest in the programs. For instance, a provider may be 
contractually obligated to maintain services for a group of existing subscribers, but 
may have otherwise turned his attention to other commercial endeavors (which may 
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be regarded as more profitable). Such a provider may have insufficient incentive to 
modify a system that is functional, but is not operating at satisfactory efficiency. 

For the above-stated reasons, some providers may administer financial 
programs using sub-optimal technical platforms for extended periods of time, such as 
sub-optimal mainframe-based technology. This may prevent the providers from 
operating their programs at satisfactory levels of efficiency. Further, the use of out- 
dated technical platforms may result in errors caused by program-related and hardware 
"glitches." The end of the millennium may present yet another time-based source of 
errors for these systems. 

It is possible to upgrade existing systems in piecemeal fashion by changing 
selected tables in a computer system's database, adding additional processing capacity, 
adding enhanced network accessibility, etc. However, if not designed carefully, such 
piecemeal improvements may result in compatibility problems between the existing 
systems and the new components. 

Even those financial providers that make a commitment to fully upgrade their 
technical platforms may not produce a satisfactory system. For instance, some forms 
of life insurance programs require frequent processing of payments from customers. 
For instance, systems known as "debit" insurance programs or "industrial insurance" 
programs require collection of life insurance premium information on a relatively 
frequently basis, such as on a weekly or monthly (or some other relatively short period 
of time). This feature may introduce a heavy load on the insurance-providing system, 
and may also place a significant burden on the personnel who must interact with the 
system to process the payments and to perform maintenance on the policies. A 
technical solution that does not adequately address the unique features of these 
"frequent-collection" services is apt to provide a system that is inefficient, error-prone, 
and/or cumbersome to use. Such factors may ultimately result in the reduced 
profitability of the insurance program. 

The patent literature includes several examples of the use of computer 
technology in the financial fields. An exemplary collection of insurance-related 
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patents include: U.S. Patent No. 5,429,506 (Method and System for Processing 
Federally Insured Annuity and Life Insurance Investments); U.S. Patent No. 5,479,344 
(Insurance Computation Display); U.S. Patent No. 5,631,828 (Life Insurance Method, 
and System); U.S. Patent No. 5,752,236 (Method of Computerized Administration of 
a Life Insurance Plan Using Computerized Administration Supervisory System); and 
U.S. Patent No. 6,041,304 (System and Method for Controlling the Cash Value 
Growth of an Insurance policy). 

However, there is no indication that the systems described in these patents will 
provide a fully sufficient solution to the above-identified problems. More specifically, 
there is no indication that these systems provide a fully satisfactory means for 
transitioning from an "existing system" to a "new system." There is also no indication 
that these systems provide a fully satisfactory means for administering some of the 
unique types of insurance programs described above, such as policies that require the 
collection of payments on a relatively frequent basis. 

There is accordingly a need for a more efficient system and method for 
administering an insurance program 

SUMMARY OF THE INVENTION 

The present invention addresses the above-identified needs, as well as 
additional unspecified needs. 

One exemplary aspect of the invention pertains to a system for administering a 
financial program involving the collection of payments. The system includes a debit 
system for coordinating the administration of the financial program, which, in turn, 
includes interface logic for allowing a user to interact with the debit system, and batch 
processing logic for performing batch processing associated with the financial 
program. The system further includes at least one support system coupled to the debit 
system for handling an aspect of the administration of the financial program, and for 
communicating with the debit system. The system further includes a data storage for 
storing data tables used by the debit system in the administration of the financial 
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program. The data storage also includes a representation of information as maintained 
by a retired system previously used for administering the financial program. 

In another exemplary aspect of the invention, the interface logic includes at 
least one of: interface logic for performing basic policy maintenance; interface logic 
for administering billing and premium payment; interface logic for performing waiver 
processing; interface logic for performing loan processing; interface logic for 
performing cash surrender value processing; interface logic for performing extended 
value processing; interface logic for performing system-related maintenance; and 
interface logic for accessing the representation of information as maintained by the 
retired system. 

In another exemplary aspect of the invention, the financial program involves 
the performance of plural processing routines to handle different aspects of the 
financial program, and the system includes functionality that facilitates interaction 
between these different processing routines. 

In a preferred embodiment, the financial program is an insurance program. In 
a further preferred embodiment, the insurance program includes payment due dates 
occurring weekly or monthly. 

BRIEF DESCRIPTION OF THE DRAWINGS 

Other features of the present invention will be apparent from consideration of 
the following Detailed Description, in conjunction with the accompanying drawings, 
in which: 

FIG. 1 shows an exemplary system for implementing the present invention; 

FIG. 2 shows an exemplary insurance processing system for use in the system 
of FIG. 1; 

FIG. 3 shows an exemplary workstation for use in the system of FIG. 1; 



Attorney Docket No. 52493 .000 1 2 1 

FIG. 4 shows an exemplary premium processing routine according to the 
present invention; 

FIG. 5 shows an exemplary loan processing routine according to the present 
invention; 

5 FIG. 6 shows an exemplary waiver processing routine according to the present 

invention; 

FIG. 7 shows an exemplary cash surrender processing routine according to the 
present invention; 

FIG. 8 shows an exemplary extended values processing routine according to 
10 the present invention; 

FIG. 9 shows an exemplary death claims processing routine according to the 
present invention; 

FIG. 10 shows an exemplary maturity processing routine according to the 
present invention; 

15 FIGS. 11-16 show exemplary screens for use in performing basic policy 

maintenance; 

FIGS. 17-22 show exemplary screens for use in performing premium billing 
and payment processing; 

FIG. 23 shows an exemplary screen for performing waiver processing; 

20 FIGS. 24-28 show exemplary screens for performing loan processing; 

FIGS. 29-33 show exemplary screens for performing cash surrender value 
(CSV) processing; 

FIGS. 34-36 show exemplary screens for performing extended term insurance 
processing; 

6 
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FIGS. 37-41 show exemplary screens for displaying and modifying system 
parameters; 

FIG. 42 shows an exemplary screen for generating an actuarial extract file; and 

FIG. 43 shows an exemplary screen for examining an error log. 

DETAILED DESCRIPTION OF THE INVENTION 

The system and method described herein are applicable to the administration 
of insurance policies generally characterized by relatively frequent payments (e.g., 
weekly, monthly, or some other interval) and relatively low benefits. This type of 
insurance is commonly referred to as "industrial insurance," "monthly debit ordinary 
(MDO) insurance," "weekly premium (WP) insurance," or "home service distribution 
insurance." Traditionally, these programs were also characterized by their use of an 
agent to personally visit the policyholders on a periodic basis to collect the premiums. 
In current manifestations, however, the policyholders may often forward their 
payments to the insurance provider using other arrangements (such as by mail, or by 
authorizing the automatic withdrawal of funds from banks accounts). A "premium" 
refers to the amount which must be contractually paid on a periodic basis to keep the 
policy in force. 

However, the system and method described herein are also applicable to other 
types of financial programs. For instance, the system and method are applicable to the 
administration of other types of insurance policies, as well as the administration of 
various loan programs, etc. 

By way of overview, section No. 1 of this application describes the 
architecture of an exemplary system for implementing the present invention. Section 
No. 2 describes various process flows used in the present invention, along with 
associated batch processing, screen presentations, etc. And section No. 3 provides a 
series of tables describing a specific exemplary implementation of the present 
invention. Section No. 3 also includes a glossary (in Table VI) for defining selected 
terms used in section Nos. 1 and 2. 
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1. System Architecture fFIGS. 1-3) 

FIG. 1 shows an overview of a system 100 for implementing the present 
invention. The system 100 features an insurance processing system 102 which 
administers the insurance program (and which is described in further detail in 
connection with FIG. 2). The insurance processing system 102 is directly connected 
to one or more workstations (such as workstations 104, 106 and 108) (which are 
described in further detail in connection with FIG. 3). One or more other workstations 
(such as workstations 1 18 and 120) may be connected to the insurance processing 
system 102 via a local network 1 16, such as a corporate intranet or like network. The 
workstations serve as "portals" for interacting with the insurance processing system 
102. Namely, users may use the workstations to enter information into the insurance 
processing system 102 and to retrieve information from the insurance processing 
system 102. 

The insurance processing system 102 may represent a "replacement" of a prior 
system (or systems) 114, now retired. The previous system(s) 1 14 represent technical 
platforms (and associated databases) that were previously used by an organization to 
administer the insurance program (e.g., before introduction of the insurance 
processing system 102). For instance, the previous system(s) 1 14 may represent one 
or more mainframe systems that were used to implement the insurance program. On 
the other hand, the insurance processing system 102 may represent a server-type 
technical platform (e.g., in the context of a client-server architecture), or some other 
updated architecture. 

The insurance processing system 102 includes a data storage 109 that contains 
information pertaining to insurance policies using multiple tables. Such information 
may include policy data that was extracted from the retired system(s) 1 14 on a 
specified conversion date (or dates) and converted to a format that is compatible with 
the insurance processing system 102 (and may thus be referred to as "converted data"). 
For example, in one embodiment, only policies that retained value as of the date of 
conversion were converted and transferred from the previous system(s) 1 14 to the 
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insurance processing system 1 02. That is, in one embodiment, policies that, at the 
time of conversion, were surrendered, matured, expired, etc., were not converted. 

That is, the insurance processing system may also include a representation (or 
"mirror") 1 15 of the retired system 114. This representation 1 15 may include a 

5 database that stores information that specifies the values of the data fields in all of the 
policies as they existed when the prior system 1 14 was converted to the new system 
(i.e., the insurance processing system 102). Such a database may reflect the data 
structure used in the prior system 114. In the illustrated embodiment, the 
representation 1 15 of the retired system 1 14 is shown as part of the data storage 109. 

10 In other embodiments, the representation 1 1 5 may be implemented as a separate 

storage module. In a further alternative embodiment, the representation 115 of the 
retired system 1 14 may also include interface logic for converting such data values 
into a format that is compatible with the insurance processing system 102. 

By virtue of this unique configuration, the insurance processing system 102 
15 may access its data storage 109 to retrieve converted records in the course of normal 
policy processing. In addition, if need be, the insurance processing system 1 02 may 
also extract data from the representation 115. For instance, the insurance processing 
system 102 may find it needful or useful to access information regarding policies that 
were not properly transferred and/or properly converted to the table structure of the 
20 new system 1 02 on the conversion date. Additional details regarding the interaction 
between the insurance processing system 102 and the "mirror" 115 of the retired 
system are provided in latter sections of this document. 

The insurance processing system 102 may also interact with one or more 
financial institutions (such as financial institutions 1 10 and 1 12). For instance 
25 financial institution 1 1 0 may comprise a bank used for forwarding notifications of 

premium payments to the insurance processing system 102. Financial institution 1 12 
may comprise a bank used for forwarding notifications of loan payments to the 
insurance processing system (in the case where a policy holder has qualified for a loan 
based on the cash surrender value of his or her insurance policy). These transfers may 
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be performed via electronic communication, or by some other means. More 
specifically, in one embodiment, policyholders may send their payments to a bank 
accompanied by a billing "stub" that identifies the billing account to which the 
payment should be applied. The bank then notifies the insurance company (e.g., 
system 102) on a daily basis that the payments have been received. This processing is 
referred to as "batch payment processing." 

Further, the insurance processing system 102 may optionally be coupled to a 
wide-area network 122, such as the Internet. Such a connection may allow remote 
users to gain access to the insurance processing system 102, e.g., via workstations 124 
and 126. Such a connection may also allow the insurance processing system 102 to 
interact with various remote resources, e.g., as implemented by one or more remote 
servers (such as server 128). 

Finally, a firewall 140 may be used to protect the integrity of data maintained 
by the insurance processing system 102. More specifically, in one embodiment, 
equipment located above the firewall 140 may be associated with an organization that 
administers the insurance program, while equipment located below the firewall 140 
may be associated with external entities that do not have a direct role in administering 
the program. The firewall 140 includes conventional functionality that prevents those 
outside the administering organization from gaining access to confidential information 
maintained by the insurance processing system 102 (and may also prevent those 
within the organization from inadvertently divulging confidential information to 
parties outside the organization). 

FIG. 2 shows an exemplary implementation of the insurance processing system 
102. The insurance processing system 102 includes a debit system 202 which serves 
as the primary "engine" for administering the insurance program. The debit system 
202 is connected to a communication interface 203, the data storage 109, and various 
insurance processing systems (such as systems 212, 214, 216 and 218), also referred 
to as "support systems." These insurance processing systems (e.g., 212, 214, 216 and 
218) are "external" to the debit system 202 in the sense that they exist independently 
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from this system (and from each other), but these systems may readily interact with 
the debit system 202 (and with each other). The communication interface 203 is used 
for interacting with the entities described above in connection with FIG. 1 (such as 
workstations, intranets, financial institutions, etc.). The data storage 109 stores 
5 various data tables used by the debit system in performing its ascribed insurance 
processing functions. For example, the data storage may store the data tables 
identified in Table I of section No. 3 below. The data storage 109 may also store the 
"mirror" 1 15 of the prior system 1 14. 

The various external systems (212, 214, 216, 218) handle different aspects of 
10 the insurance program. For instance, the death claims system 212 administers the 

processing and disposition of claims pertaining to the death of a policy-holder. More 
precisely, a "death claim" refers to a request for payment under the terms of an 
insurance policy upon the death of the insured. 

The matured endowment system 214 administers the processing and 
15 disposition of claims pertaining to a matured endowment. A policy "matures" when it 
reaches the date on which the cash value of the policy equals the face amount of the 
insurance paid by the policy. A "matured endowment" refers to an insurance policy 
where the cash value has become equal to the face amount of the insurance paid by the 
policy (and the insured is still living). 

20 The waiver of premium system 2 1 6 handles aspects of the insurance program 

pertaining to the waiver of premiums. "Waiver processing" refers to processing 
carried out when insurance premiums are waived because the insured has become 
disabled and the policy carries a disability rider. (A "rider" generally refers to 
additional or "secondary" coverage under an insurance policy). After a policy has 

25 gone into premium-waiver status (i.e., "WAIV" status), the premiums are in essence 
paid by the insurance company. If the insured does not remain disabled indefinitely, 
the policy may resume its premium-paying status. 



The debit system 202 may also communicate and interact with various other 
systems 218, which may handle other aspects of the insurance program. 

11 
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The debit system 202 itself may include various functional modules for 
performing its ascribed functions. For instance, the debit system 202 includes 
interface logic 204 for providing various interface screens (e.g., shown in FIGS. 11- 
43) for use by workstation users in interacting with the insurance processing system 
102. More specifically, the interface screens comprise Graphical User Interface (GUI) 
pages used to interact with records stored in data storage 109. The debit system 202 
may also include batch processing logic 206 for performing various processing and 
reporting on a batch-related basis (e.g., as exemplified by the processing and reporting 
identified in Tables II and III below). More specifically, "batch processing" refers to 
the computer-processing of information extracted from a database, carried out on a 
relatively large scale basis. Such processing is often performed during nighttime 
hours when users are not online using the system 102. 

The interface logic 204 and batch processing logic 206 further incorporate 
interaction functionality which permits different aspects of the system 102 to 
communicate with each other. For instance, aspects of the system 102 which handle 
loan processing should be able to interact with aspects of the system 102 which handle 
cash surrender value processing (since coverage will cease if a loan balance exceeds 
cash surrender value). Further, for example, aspects of the system 102 which handle 
premium billing and payment processing should be able to interact with aspects of the 
system 102 which handle policy maintenance processing (since premiums will change 
if coverage changes). Thus, in general terms, the system 102 may be said to involve 
the performance of plural processing routines to handle different aspects of a financial 
program, and the system includes functionality that facilitates interaction between 
these different processing routines. 

Further, the debit system 202 may include other processing logic 208 for 
handling other aspects of its ascribed functions, such as logic for generating on-line 
reports, logic for interacting with the various external support system (such as the 
death claims system 212 and the matured endowment system 214), etc. The logic 
(204, 206, 208, etc.) may be implemented as machine code which performs various 
functions when executed by a processor. The "output" of the debit processing system 
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includes, in part, interface screen presentations supplied via the communication 
interface 203, and various hard-copy reports and on-line reports (generically 
represented as reports 222). 

The insurance processing system 102 may be implemented using various 
architectures. For instance, the system 102 may be implemented as a server computer 
unit (in the context of a client-server architectural environment). For example, the 
system 102 may include a server computer having conventional components (e.g., 
processor, memory, cache, interface means, etc.) running the Microsoft Windows™ 
NT™, Windows™ 2000, Unix, Linux, Xenix, IBM ADC™, Hewlett-Packard UX™, 
Novell Netware™, Sun Microsystems Solaris™, OS/2™, BeOS™, Mach, Apache, 
OpenStep™ or other operating system or platform. In one embodiment, the system 
102 may comprise a single computer. Alternatively, the system 102 may comprise 
multiple computers connected together in a distributed fashion, each of which may 
implement/administer a separate aspect of the insurance program. The equipment 
associated with the system 102 may be located at a central facility, or, in an alternative 
embodiment, may be distributed over plural facilities. 

In one embodiment, a single computer (e.g., a single server-type computer) 
may implement the debit system 102 and the various related external support systems, 
such as the death claims system 212, the matured endowment system 214, the waiver 
of premium system 216, etc. In another embodiment, separate computers may be used 
to implement each of the above-identified systems. Those skilled in the art will 
appreciate that still other allocations of processing functionality are possible to suit the 
demands of different applications. 

The data storage 109 may comprise a single data storage unit or multiple units 
connected together in a distributed fashion. The data storage 109 may be 
implemented using an Oracle™ relational database sold commercially by Oracle 
Corp. Other databases, such as Informix™, DB2 (Database 2), Sybase or other data 
storage or query formats, platforms or resources such as OLAP (On Line Analytical 
Processing), SQL (Standard Query Language), a storage area network (SAN), 
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Microsoft Access™ or others may also be used. The data storage 109 may physically 
store its data using any type of storage medium, such as any type of magnetic disk or 
tape, any type of optical media, etc. 

As described above, the data storage 109 includes converted data records 
representing information converted from the retired system 1 14 on the conversion 
date(s), as well as the representation 1 15 of unconverted information as maintained in 
the retired system 1 14 on the conversion date. The converted data may reflect the data 
structure used by the updated system 102 (e.g., as reflected by the data tables that 
appear in Table I of section No. 3 below), while the representation 115 may reflect the 
retired system's 114 data structure. The preservation of the "old" data in this fashion 
is an efficient and powerful mechanism for transitioning from the old system 1 14 to 
the new system 102. 

FIG. 3 shows an exemplary workstation for interacting with the system 100 of 
FIG. 1 . The workstation represents any type of general or special purpose computer 
comprising conventional hardware. Namely, the work station includes a processor 
3 14 connected, via bus 3 10, to a Random Access Memory (RAM) 304, Read Only 
Memory (ROM) 306, and storage device 308 (hard drive, CDROM, optical disc, etc.). 
The work station further includes an interface unit 302, which, in turn, includes one or 
more devices 318 for inputting information (such as a keyboard, mouse-type input 
device, touch screen or panel, etc.), and one or more devices 3 16 for rendering 
information (including a display, printer, etc.). In one exemplary embodiment, the 
interface unit 302 presents the screens identified in FIGS. 1 1-43. The workstation 
also includes a communication interface device 312 (such as a modem, etc.) for 
interacting with external equipment (such as the insurance processing system 102, or 
intranet 116). The computer may operate using any one of a variety of operating 
programs, such as the Microsoft Windows™ 98 program. 

2. Process Flow and Related Features (FIGS. 4-43) 

The process flow used in administering the insurance program may be divided 
into the following categories: premium billing and payment processing; loan 
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processing; waiver of premium processing; cash surrender processing; extended value 
processing; death claims processing; maturity processing; and miscellaneous system- 
related maintenance. 

By way of overview, premium billing and payment processing refers to 
5 printing and mailing billing statements, and then applying payments that are received 
(e.g., crediting the payments to particular policies), as well as related processing tasks. 
In connection therewith, a "premium" refers to a minimum amount which must be 
paid on a periodic basis (as contractually agreed) to keep the policy in force. 

Loan processing refers to various tasks associated with establishing and 
10 administering loans, such as setting up a loan on a policy, charging annual interest, 

billing annual interest, recording payments against principal or interest, collection and 
processing of minimum interest payments (when outstanding interest becomes greater 
than the policy value), etc. 

Waiver of premium processing pertains to various tasks performed when a 
15 waiver is placed on a policyholder's policy (such as when the policyholder becomes 
disabled). 

Cash surrender processing pertains to various task performed in connection 
with the conversion of a policy to its cash value equivalent, thereby terminating the 
policy. More specifically, the cash value of a policy refers to the amount of money at 
20 any given time during the life of a policy that the policyholder will receive if he or she 
cancels the coverage and surrenders it to the insurance company. A policyholder 
surrenders a policy for cash by stopping premium payments on the policy, and 
requesting the cash surrender non-forfeiture option, thereby receiving payment of the 
cash value of the policy. 

25 Extended term insurance refers to a non-forfeiture option associated with a 

policy whereby the net cash value of the policy is applied as a single net premium to 
purchase term insurance. Extended value processing refers to various processing 
performed (e.g., computation of cash surrender value, etc.) in order to lapse a policy to 
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extended term status. 

Death claim processing refers to various tasks performed when a death claim 
is filed on a policy. A "death" claim refers to a request for payment under the terms of 
an insurance policy upon the death of the insured. 

Maturity processing refers to various tasks performed when an insurance 
policy reaches maturity. A policy matures when it reaches the date on which the cash 
value of the policy equals the face amount of insurance paid by the policy. 

The miscellaneous system-related maintenance processing refers to various 
administrative tasks, such as the review of error logs, generation of an extract file, etc. 

2(a) Premium Processing (FIG. 4) 

2(a-i) Overview 

FIG. 4 shows an exemplary routine for performing premium processing using 
the system 100 of FIG. 1 with respect to one exemplary customer. By way of 
overview, the process includes an initial step 402 of sending out information to the 
customer, e.g., via the mail service or via electronic transmission. This step may 
specifically entail sending out a Monthly Debit Ordinary (MDO) coupon book (in 
substep 404). This coupon book conventionally contains a series of statements that 
identifies the payments required for a series of premium due-date intervals (e.g., for a 
series of months within a year). This step may further include sending out a premium- 
due reminder notice for a Weekly Premium (WP) policy (in substep 408). This step 
may further include sending out new billing account notices (in substep 410). 

In step 412, the system 1 00 determines whether a payment has been received 
by the appropriate due date. If not, in step 414, the system 100 sends out a lapse 
notice. In step 416, after a prescribed period of days (e.g., 90 days), the system 
converts the policy to extended term status. Alternatively, if a payment is received, 
the system 100 applies the payment to the respective policy account (in step 418). 
Then, in step 420, the system 100 performs appropriate post-payment processing. 
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This processing may include sending out payment-received acknowledgment letters 
that serve also as billing statements (in substep 422), updating the policy status (in 
substep 424), and generating a refund if required (in substep 426). 

2(a-ii) Premium Batch Processing and Reporting 

A subset of the batch programs and reports identified in Tables II and III (in 
section No. 3 below) may be used to perform selected steps in the above-described 
procedure. For instance, a DB_PAYMENT_PKG routine processes notification of 
payments sent by financial institutions (e.g., banks). More specifically, this routine 
detects matching and non-matching payments. (A matching payment refers to a 
payment having a dollar amount that matches a multiple of the policy's modal 
premium.) This routine also creates payment transactions for the matching payments 
and "holding" transactions for the non-matching payments, as appropriate. A holding 
transaction refers to a transaction that records a payment against a particular policy or 
account but does not "apply" the payment because the payment amount does not 
match a billed amount and therefore it is not yet known how the payor intended the 
payment to be applied. Holding transactions may be applied via online entry when the 
desired distribution of funds has been determined. This routine also produces a 
premium payments listing, generates acknowledgement letters for matching payments, 
and, if a payment takes a policy to its "paid up date" (i.e., captured by the 
PAID UPDATE variable), performs appropriate close-out processing. (The "paid up 
date" refers to the calendar date as of which all premium payments contractually 
agreed to under the terms of a policy will have been paid.) 

A DB L AP SEPP A Y routine identifies the premium paying policies having a 
PAID TO DATE field that is 90 days or more in the past, where the account status is 
active, "A." On finding such a billing account, this routine determines if there are still 
policies attached to it having a "PPAY" (premium-paying) status. (The PPAY status 
indictes that a policy is in force and requires additional premium payments to remain 
in force, because it is not yet paid up.) If so, this billing account and its policies are 
lapsed (that is, converted to extended term status). 
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The system may generate various premium-related batch reports, such as an 
acknowledgement letter for payment, notice of policies with lapse pending in the next 
calendar month, notice of lapsed MDO premium due, notice of lapsed weekly 
premium due, notice of policies lapsed for non-payment of premium, notice of 
policies not premium-paid for 31 days, notice of minimum interest due on a loan for 
premium paying policies, WP reminder notice, etc. 

The debit system 202 also provides a number of on-line reports pertaining to 
the above-described processing, as identified in Table V in section No. 3 below. 

2(a-iii) Premium Processing and Related Maintenance Interface Screens 

A subset of screens identified in Table IV (in section No. 3 below) may be 
used to facilitate performance of selected steps in the above-described procedure, 
and/or for performing maintenance processing associated with the policies. For 
instance, a Policy Data Screen (FIG. 1 1) pulls up policy details in response to input of 
a policy number. The "UPDATE INSURED NAME" and "UPDATE BENEFICIARY 
NAME" buttons on the screen allow the user to modify the beneficiary and insured 
names, respectively. Further, it is possible to enter an entirely new policy onto the 
system by clicking the "RESTORE LOST POLICY" button. This allows the user to 
add policies that were somehow lost on the old system 1 14 and therefore were not 
transferred to the new system 1 02. Thus, although the business entity currently using 
this system may no longer be selling new policies, the system 102 itself contains the 
functionality necessary to accept new policies in the event that it were to be used by a 
business entity that desired such functionality. 

A Policy Coverage Screen (FIG. 12) allows the user to add or modify coverage 
record details for a policy in response to input of a policy number. This screen 
maintains base coverage plus riders and benefits. The "base" coverage of a policy 
refers to insurance provided to a "primary" party identified in the policy. The 
"benefit" associated with a policy refers to an amount of money to be contractually 
paid under the policy when certain events occur, such as the death of the insured. As 
noted above, a "rider" refers to additional or "secondary" coverage under an insurance 
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policy. 

A Policy Status Screen (FIG. 13) retrieves the status of a policy for various 
date ranges. Further, the user can query on an existing policy number to retrieve 
status information pertaining to the policy. Further, the "GENERATE REFUND" 
button allows the user to generate a premium refund for policies that have become 
paid up, if appropriate. The "REVERSE REFUND" button allows the user to reverse 
the refund operation. Generally, a refund is appropriate when excess payments have 
been received for some reason. 

A Policy Summary Screen (FIG. 14) provides summary details for a policy in 
response to the input of a valid policy number. In one embodiment, this screen does 
not permit users to modify the data presented on the screen. Assistance personnel 
employed by the insurance organization may use this screen to answer questions 
posed by policyholders who contact the personnel via telephone, or other 
communication means. 

A Policies Not Converted Screen (FIG. 15) presents information that 
represents (or "mirrors") data once stored on the prior system 114, and is now 
maintained in the mirror system 115. Hence, in one embodiment, this screen may be 
used to retrieve all of the information that was maintained on the prior system 1 14 at 
the time of conversion. This feature reduces the risk of losing data in the conversion 
process. 

A Policy Maturity Year Screen (FIG. 16) allows a user to make corrections to 
maturity dates for policies. More specifically, this screen lists policies having blank 
(i.e., unspecified) maturity dates because the data was lost on the previous system. 
Users may query on "Maturity Year ," "Policy Begin," or "Policy End." A user may 
view the maturity dates corrected by a particular user by querying on user ID and 
placing a check in the "Corrected Maturity Dates" checkbox. This feature is an 
example of the new system's facilitated ability to make corrections to data that was 
corrupted as maintained in the prior system 1 14. 
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A Premium Billing Account Screen (FIGS. 17 and 18) presents billing account 
details in response to input of Account number, Account status, Paid to Date, 
Discount Code, or Policy Type (e.g., WP, MDO). This screen enables the user to add 
or remove policies for a billing account. Further, this screen enables a user to add a 
new billing account. 

A Billing Account Policy Association Screen (FIG. 19) shows the association 
between a premium billing account and its policies. The screen enables users to query 
on either policy number, billing account number, or both. Further, this screen allows 
users to add policies or remove policies associated with a particular billing account. 

A Billing Account Transaction Screen (FIG. 20) permits the user to fetch 
premium billing account transaction details, as well as enter new payment 
transactions, by entering a valid billing account number. When the user enters the 
"Amount Received" and invokes the "APPLY PAYMENT" button, the system 
calculates the number of modal premiums paid, and adjusts the paid to date on the 
policy to reflect the payment. 

A Policy Modal Premium Information Screen (FIG. 21) retrieves modal 
premiums for policies in a specified date range. The screen allows a user to query on 
an existing policy number and then add a new modal premium (when premiums 
change because of changes in coverage), as well as its start date. 

A Premium Refund Information Screen (FIG. 22) allows a user to view and 
make premium refunds. In operation, the screen enables a user to query on a policy 
number and then generate a refund or reverse a refund by pressing the "GENERATE 
REFUND" and "REVERSE REFUND" buttons, respectively. 

2(b) Loan Processing (FIG. 5) 

2(b-i) Overview 

FIG. 5 shows an exemplary routine for performing loan processing using the 
system 100 of FIG. 1 with respect to one exemplary customer. By way of overview, 
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the process includes an initial step 502 of providing a quote to the customer, and 
subsequently processing the customer's application for insurance coverage. Then, in 
step 504, the process entails sending out notices/statements to the customer, e.g., via 
the mail service or via electronic transmission. This step may specifically entail 
sending out an interest due billing statement (in substep 506). This step may further 
include sending a minimum interest due notice when total loan balance exceeds policy 
value (in substep 510). 

In step 512, the system 100 determines whether payment has been received by 
the appropriate due date. In step 5 14, if minimum interest is due and payment has not 
been received after the due date, the system 100 lapses the policy. Alternatively, in 
step 516, if a payment is received, the system 100 automatically or manually applies 
the payment as principal or interest to the customer's accounts. Then, in step 518, the 
system 100 performs appropriate post-payment processing. This processing may 
include sending out payoff letters if a loan is paid off (in step 520), generating a 
refund if required, and crediting the account with unearned interest (since interest is 
charged in advance) (in substep 522). 

2(b-ii). Loan Batch Processing and Reporting 

A subset of the batch programs and reports identified in Tables II and III (in 
section No. 3 below) may be used to perform selected steps in the above-described 
procedure. For instance, a DB LOAN PKG program processes batch payment 
notices coming from the bank(s) and inserts into the appropriate data storage table(s) 
indications of matching (payment equals interest due) and non-matching payments. 
More specifically, this routine: (1) sorts bank batch files containing premium and loan 
payments for the debit system; (2) combines the batch information with detail records; 
(3) detects matching and non-matching payments; (4) creates payment transaction 
records and updates minimum interest transaction records (MININT) to record 
payments as appropriate; and (5) produces a loan interest payment collection report. 
Non-matching payments are "held" in storage until a user determines the desired 
distribution of funds and applies this distribution via screen interfaces. 
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A DBJSfPAY MININT program identifies the policies with minimum interest 
due. More specifically, this routine looks for any MININT policy loan transaction 
where the ANNU AL_INTERE ST_DUE DATE field is 30 or more days in the past 
and the transaction amount is equal to 0 and lapses the affected policies (policy status 
changes to LPNVL, i.e., lapsed with no value). 

The debit system 202 also provides a number of on-line reports pertaining to 
the above-described processing, as identified in Table V in section No. 3 below. 

2(b-iii) Loan Processing and Related Maintenance Interface Screens 

A subset of screens identified in Table IV (in section No. 3 below) may be 
used to facilitate performance of selected steps in the above-described procedure, 
and/or for performing maintenance processing associated with the loans. For instance, 
a Loan Maintenance Screen (FIGS. 24 and 25) retrieves the loan transactions for a 
policy in response to entry of a valid policy number. A user may view the loan details 
(such date due, minimum interest due, etc.) by pressing the arrow button (in lower 
right of screen). Further, the screen allows a user to add a new loan for the displayed 
policy. Further still, this screen enables a user to modify the "Payor Name" and 
"Address." In this particular exemplary application, a user may also modify the 
subscriber's Florida Name and Address (for secondary billings required by Florida 
statute). 

A Loan Approval and Loan Quote Screen (FIGS. 26 and 27) allow the user to 
process new loans. More specifically, the screens enable a user to query on an 
existing policy number to view the loan details. In order to process a new loan, the 
screen prompts the user to enter a policy number, loan date, and loan amount. In one 
embodiment, the loan amount should be less than the cash surrender value (CSV) for 
the policy and processing associated with the screen determines if this is true. When 
the user presses the "Loan Approval" button, the system approves or denies the loan ( 
depending on the CSV). The screen indicates whether the system has approved or 
denied the loan by posting a " Y" or "N" symbol in the "Approval Indicator" field. 
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A Policy Loan Screen (FIG. 28) retrieves loan details for the policies. This 
screen allows the user to modify the interest rates applicable to the loans. 

2(c) Waiver of Premium Processing (FIG. 6) 

(c-i) Overview 

FIG. 6 shows an exemplary routine for performing waiver of premium 
processing. By way of overview, the process includes an initial step 602 of placing a 
policy on waiver. As mentioned above, this action may be appropriate where the 
policyholder is excused from paying the premium for a prescribed amount of time, 
because of, for instance, his or her disability, provided that a disability rider is present 
on the policy. In step 604, the process includes updating the policy to waiver status 
(i.e., "WAIV" status). In step 606, premiums paid during the waiver period can be 
refunded. In step 608, the process includes updating paid-to-date information on a 
periodic basis. And in step 610, the process includes terminating the waiver when 
required. 

2(c-ii). Waiver of Premium Processing Batch Processing and Reporting 

A subset of the batch programs and reports identified in Tables II and III (in 
section No. 3 below) may be used to perform selected steps in the above-described 
procedure. For instance, a DBWAIVPTDJJPDATE routine updates the waived 
policy's paid to date. More specifically, this routine detects any policies on waiver 
(current policy status = "WAIV") where the PAID_TO_DATE field should be 
updated. 

Other batch reports that may be generated include notice of loan minimum 
interest due for policies on waiver, etc. 

The debit system 202 also provides a number of on-line reports pertaining to 
the above-described processing, as identified in Table V in section No. 3 below. 

2(c-iii) Waiver of Premium Processing Interface Screens 
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A subset of screens identified in Table IV (in section No. 3 below) may be 
used to facilitate performance of selected steps in the above-described procedure. For 
instance, a Premium Refund Information Screen (FIG. 23) retrieves policies along 
with the date ranges for which the policies are in waiver state. The user can instruct 
the system to generate a refund for premiums paid during the waiver period by 
invoking the "Generate Refund" button. In response, the system generates a Refund 
Sequence No. for that policy. A user may instruct the system to perform a reverse 
refund transaction (if needed) by invoking the "Reverse Refund" button. Further, a 
user can terminate the waiver status for a policy by invoking the "Terminate Waiver" 
button. A user may also reverse such termination by pressing the "Reverse 
Termination" button. 

2(d) Cash Surrender Processing (FIG. 7) 

2(d-i) Overview 

FIG. 7 shows an exemplary routine for cash surrender processing using the 
system 100 of FIG. 1 with respect to one exemplary customer. By way of overview, 
the process includes an initial step 702 of providing a cash surrender value (CSV) 
quote to a customer. If the customer opts to "surrender" his or her policy, in step 704, 
the system 100 performs various CSV processing, such as calculating the CSV based 
on the rate book and outstanding loan amount, etc. In step 706, the system 100 
updates the policy status to indicate that that policy has been "surrendered" (i.e., now 
has "SURR" status). And in step 708, if requested (or appropriate), the system 100 
performs cash surrender reversal. 

2(d-ii). Cash Surrender Batch Processing and Reporting 

A subset of the batch programs and reports identified in Tables II and III (in 
section No. 3 below) may be used to perform selected steps in the above-described 
procedure. For instance, a DB_CALC_CSV routine returns the cash surrender value 
(CSV) for a policy. This same CSV calculation routine is used in a 
DB_LOAN_BILLING_MININT routine for generating loan interest billing to check if 
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minimum interest is due and to generate a minimum interest due (MININT) 
transaction accordingly. This routine calculates the cash surrender value by fetching 
the appropriate records from the data storage 109 (such as a CSV_RATE table). The 
function returns a value of "-1 " in case of any errors that occur when running the 
routine. 

The debit system 202 also provides a number of on-line reports pertaining to 
the above-described processing, as identified in Table V in section No. 3 below. 

2(d-iii) Cash Surrender Processing Interface Screens 

A subset of screens identified in Table IV (in section No. 3 below) may be 
used to facilitate performance of selected steps in the above-described procedure. For 
instance, a Cash Surrender Quote Screen (FIG. 29) allows the user to query on a valid 
policy number to retrieve the Cash Surrender Value (CSV) details for the 
corresponding policy. In one embodiment, the screen does not permit users to modify 
any of the fields on the screen. 

A Cash Surrender Processing Screen (FIG. 30) allows users to generate and 
reverse cash surrender value transactions for an identified policy. The screen permits 
the user to query on an existing policy number. By invoking the "Cash Surrender" 
button, the system calculates the CSV amount for the identified policy, generates a 
surrender transaction against the policy, and changes the policy status to "SURR." 
The user may reverse the surrendered policy by activating the "Reverse" button. 

A CSV Rate Screen (FIG. 31) retrieves and displays a Cash Surrender Value 
factor table. The system calculates the CSV amount for a policy using this CSV factor 
table. In one embodiment, the screen does not permit the user to add or modify the 
rate books. 

A Plan Code Screen (FIG. 32) retrieves the plan codes and the corresponding 
plan descriptions from the data storage 109. The screen allows a user to add or 
modify plan codes. 
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A Policy CSV Transaction Screen (FIG. 33) retrieves the CSV transaction 
records for a policy. The screen permits a user to add a new CSV transaction, or to 
modify an existing CSV transaction. 

2(e) Extended Value Processing (FIG. 8) 

2(e-i) Overview 

FIG. 8 shows an exemplary routine for performing extended value processing. 
By way of overview, the process includes an initial step 802 of registering the 
automatic or manual lapsing of a policy. In step 804, the system 100 calculates the 
cash surrender value (CSV) of the policy based on the rate book and the outstanding 
loan amount. In step 806, the system 100 updates the policy to indicate that extended 
value processing has taken place. In step 808, the system 1 00 reverses the lapse to 
extended term (returns the policy to premium-paying status) if required (or 
appropriate). 

2(e-ii) Extended Value-Related Interface Screens 

A subset of screens identified in Table IV (in section No. 3 below) may be 
used to facilitate performance of selected steps in the above-described procedure. For 
instance, an Extended Values Main Screen (FIG. 34) allows a user to modify the 
policy status to an Extended Term Insurance (ETI) status or a Reduced Paid Up (RPU) 
status. In operation, the user calls up a policy by entering a valid policy number. The 
system calculates CSV amount and the number of years of extended term or the 
reduced paid up coverage available from that amount. The system then adds this 
information to an appropriate table in the data storage 109 and changes the status of 
the policy to ETI or RPU depending on whether the Extended Term Insurance or 
Reduced Paid Up options are selected, respectively. 

An Extended Term Insurance Screen (FIG. 35) retrieves the details of an 
Extended Term Insurance status policy when the user inputs a valid policy number of 
the LPNVL or ETI type. The screen permits the user to restore the status to its prior 
state by activating the "Reverse" button. 
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A Reduced Paid Up Screen (FIG. 36) retrieves details of a RPU status policy 
in response to the user inputting a valid policy number of the RPU status. In one 
embodiment, the screen permits the previous status of the policy to be restored by 
pressing the "Reverse" button. 

An Extended Rate Screen (FIG. 37) retrieves the extended rate factor table 
used during conversion of a policy to ETI-status. In one embodiment, the screen does 
not permit the user to add or modify the rate book. 

2(f) Death Claim Processing (FIG. 9) 

2(f-i) Overview 

FIG. 9 shows an exemplary routine for performing death claims processing 
using the system 100 of FIG. 1 with respect to one exemplary customer. By way of 
overview, the process includes an initial step 902 of receiving a request from an 
external system for policy information. In response to this request, in step 904, the 
system 100 updates the policy status to death claim filed (i.e., "DTHF"). In step 906, 
the system sends requested policy information to the claims system. 

Another aspect of the death claims processing includes an initial step of 
receiving an indication that a death claim has been paid or cancelled (in step 908). 
Then, in step 910, the system updates the policy status to indicate that the death claim 
has been paid ("DTHP"). In the case of a cancellation of the claim, the system 100 
reinstates the policy status that existed prior to cancellation. 

2(f-ii). Death Claim Batch Processing and Reporting 

A subset of the batch programs and reports identified in Tables II and III (in 
section No. 3 below) may be used to perform selected steps in the above-described 
procedure. For instance, a DB DC INTERFACE PRC routine interacts with the 
death claims system 212. More specifically, the death claims system 212 creates a file 
when a death claim is filed. On a daily basis, the debit system 202 checks for the 
existence of such a request for information file from the claims system 212. If 
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present, the DB_DC_INTERFACE_PRC routine reads the file and generates a return 
file with policy and payee information for the policies associated with death claims 
identified in the request file. More specifically, for each record in the request file, the 
debit system 202 determines what information is required by the claims system 212, 
and then obtains that information. For instance, if the death claim system's file 
indicates that a claim is being set up, then the debit system 202 calls a 
DB_DC_INT_CLAIM_SETUP_PRC routine to change the existing policy status to 
the "DTHF" status. If the death claim system's file indicates that the death claim has 
been paid, then the debit system 202 calls a DB DC INT CLAIM SETTLE PRC 
routine to change the policy status from "DTHF" to "DTHP." If the death claim 
system's file indicates that the death claim has been deleted, then the debit system 202 
calls a DB_DC_INT_CLAIM_CANCEL_PRC routine to delete the DTHF status and 
restore the policy's previous status. A DB_DC_INTERFACE_WRITE_PRC routine 
generates the policy and payee information required by the death claims system 212. 
A DB DC INT REQNF PRC routine processes the death claim system's request 
when the identified policy is not found in the debit system 202. 

The debit system 202 also provides a number of on-line reports pertaining to 
the above-described processing, as identified in Table V in section No. 3 below. 

2(z) Maturity Processing (FIG. 10) 

2(g-i) Overview 

FIG. 10 shows an exemplary routine for maturity-related processing using the 
system 100 of FIG. 1 with respect to one exemplary customer. By way of overview, 
the process includes a step 1002 of sending policy information every end of the month 
to the external matured endowments system 214 for policies maturing the subsequent 
month. In step 1004, the system then updates the policy status to "MATF" (maturity 
filed). 

Another aspect of the maturing processing in FIG. 10 includes an initial step of 
receiving, from the matured endowments system 214, information that the maturity 
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claim has been paid (in step 1006). Then, in step 1008, the system updates the policy 
status to "MATP" (maturity paid status). 

2(g-ii). Maturity Batch Processing and Reporting 

A subset of the batch programs and reports identified in Tables II and III (in 
section No. 3 below) may be used to perform selected steps in the above-described 
procedure. For instance, a DB DC ME RE SPRE ADPRC routine reads an 
interface file "DC_ME_LAPSES.TXT" generated by the matured endowments system 
214 and updates the policy status for policies having settled maturity and death claim 
statuses. More specifically, this routine calls a DB_DC_ME_RESP_UPD_PRC 
routine to close the "MATF" status of the policies identified in the 
DC_ME_LAPSES.TXT." That is, this routine changes the "MATF" status (maturity 
filed) to the "MATP" status (maturity paid) in the POLICY_STATUS table. 

A DB LIFE MAEX PR PRC program identifies the policies about to mature 
or expire and changes the status of appropriate tables in the data storage 109 to reflect 
this event. More specifically, this routine examines the data storage every month end 
to determine policies that will mature or expire in approximately 30 days. 

Other batch reports that may be generated include a report that identifies in- 
force policies due to mature in the next calendar month, extended term or reduced 
paid up policies due to expire or mature in the next calendar month, policies on 
waiver due to mature, etc. 

The debit system 202 also provides a number of on-line reports pertaining to 
the above-described processing, as identified in Table V in section No. 3 below. 

2(h) Miscellaneous Maintenance Processing 

2(h-i) Overview 

The system 100 includes other routines for handling maintenance on the 
system 100. Such routines permit users to change system parameters, view error log 
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information, etc. 

2(h-ii). Miscellaneous Maintenance Batch Processing and Reporting 

A subset of the batch programs and reports identified in Tables II and III (in 
section No. 3 below) may be used to perform system-related maintenance. For 
instance, an DB_ERRORS_LOGJPRC routine logs the errors that occur in the course 
of running the debit system's routines. More specifically, this routine logs details such 
as program ID, error line, Oracle error number, Oracle error message, etc. in an 
DB ERRORS table. 

A DB GEN ACC EXTRACT routine generates an accounting extract file 
"EXTRACT.TXT" for "WP" and "MDO" debit modes when policies with loans are 
lapsed. More specifically, this routine fetches the records from appropriate tables in 
the data storage 109 and generates the extract file "EXTRACT.TXT." 

A DB_INVALID_BILL_ACC_PRC routine sets ACCOUNT_STATUS to "I" 
if the account is invalid. More specifically, this routine examines all records in a 
billing account table in the data storage 109 in which ACCOUNT_STATUS = "A" 
(Active). The routine then locates any accounts that are invalid. 

A DB MONTLY COUNTS routine maintains various counts and sums in a 
table stored in the data storage 109. In one embodiment, data from this table provides 
statistical displays on an intranet website. More specifically, the first day of the next 
month relative to the input date is computed and the counts and sums are calculated 
for this first day of the next month. Some of the counts that are computed include: (1) 
number of premium paying life policies with MDO and WP debit modes; (2) number 
of premium paying health policies with MDO and WP debit modes; (3) number of life 
policies with MDO and WP debit modes in waiver state; (4) YTD (Year To Date) 
premium payment amounts for MDO and WP debit modes; (5) number of policies of 
extended term insurance type (ETI) with MDO and WP debit modes; (6) number of 
policies of reduced paid up (RPU) type with MDO and WP debit modes; (7) YTD 
number of policies surrendered with MDO and WP debit modes; (8) YTD number of 
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policies with death claim processed (DTHP) having MDO and WP debit modes; (9) 
YTD number of policies with matured endowment processed (MATP) having MDO 
and WP debit modes; (10) YTD number of lapsed life policies with MDO and WP 
debit modes; (11) number of paid up policies with MDO and WP debit modes; (12) 
total annual premium for premium paying life policies with MDO and WP debit 
modes; and (13) total annual premium for health policies with MDO and WP debit 
modes. 

The debit system 202 also provides a number of on-line reports pertaining to 
the above-described processing, as identified in Table V in section No. 3 below. 

2(h-iii) Miscellaneous Maintenance Processing Interface Screen 

A subset of screens identified in Table IV (in section No. 3 below) may be 
used to facilitate performance of selected steps in the above-described procedure. For 
instance, an Access Role Entry Screen (FIG. 38) permits an administrator to control 
access to the interface screens. More specifically, this screen pulls up a list of roles 
and privileges currently applicable for the screens. The screen permits the user to add, 
modify or delete access roles and privileges for the screens. 

An Error Message Entry Screen (FIG. 39) retrieves and displays error 
messages (along with associated error types and error numbers) generated by the debit 
system's screens. 

A Report Definition Screen (FIG. 40) retrieves and displays valid report IDs 
and associated report names and run modes (specifying whether report is online or 
batch). The screen permits a user to add, modify or delete a report. 

A Form Definition Screen (FIG. 41) retrieves all of the valid screen IDs and 
screen names in the debit system from the data storage 1 09. The screen permits a user 
to add, modify or delete ID and name information. 

An Actuarial Extracts Screen (FIG, 42) allows a user to generate an actuarial 
extract file for use by actuarial personnel within an organization. In operation, the 
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user enters the date and desired location of the extract file to be output. The user then 
creates the actuarial extracts file by pressing the "Generate Extracts" button. 

An Error Log Screen (FIG. 43) retrieves the details of the errors generated 
during execution of the batch programs (which are trapped in the DBERRORS 
5 table). The screens allows a user to query on the batch "Program name," "Run by," or 
"Run date" fields to retrieve the error messages. 

3. Tables Describing Detailed Exemplary Embodiment 

The following tables, in conjunction with FIGS. 1 1-43, identify a detailed 
exemplary embodiment of the present invention. Namely, Table I describes 

10 exemplary data tables that may be used to store data in the data storage 1 09 of the 
insurance processing system 102 of FIG. 2. Table II identifies exemplary batch 
programs for use in administering the insurance program. Table III identifies 
exemplary batch reports that are generated by the system of FIG. 1 . Table IV, in 
conjunction with FIGS. 1 1- 43, identify exemplary screens for interacting with the 

15 system 1 00 of FIG. 1 . And Table V describes exemplary on-line reports that may be 
generated by the system 100 of FIG. 1. 



Table I: Data Model 



Table Name 


Variables 


BATCH_PROCESS_CONTROL 


PAYPROCESS DONE_DATE; 
LOANPROCESS DONE DATE 


BILLINGACCOUNT 


BILLING ACCOUNT NO; DISCOUNT_CODE; 
ACCOUNT STATUS; DEBIT MODE; PAIDTODATE; 
DATE LAST PAID; PARTIAL PAYMENT_B ALANCE ; 
NEXT COUPON BOOK DATE; CHECK_DIGIT; 
LAPSE NOTICE_SENT; DATE_LAST_MODIFIED; 
MAINT USER ID 


BILLINGACCOUNTPAYOR 


BILLING ACCOUNT NO: PAYOR ID NO; 
PAYOR TYPE; START DATE; STOP DATE; 
DATE LAST MODIFIED; MAINT USER ID 


BILLING_ACCOUNT TRANS 


BILLING ACCOUNT NO; PAID TO_DATE; 

NO OF MODAL PREMS PAID; DEBIT_TRANS_TYPE; 

TRANSACTIONMETHOD; DATE_RECEIVED; 

AMOUNT RECEIVED; 

PREMIUM PAYMENT AMOUNT; 

PARTIAL PAYMENT; REFUND INDICATOR; 

REFUND SEQ NUMBER; REMINDER NOTICE SENT; 
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Table Name 


Variables 




DESCRIPTION; LATE_NOTICE__SENT; 
PAYMENTAPPLIEDFLAG ; CHECKJDIGIT; 
CS BATCH NUMBER; CS SEQUENCE NUMBER; 
ACKJLETTER_SENT; D ATE LAST MODIFIED ; 
MAINT USER ID 


CSV_RATE 


PLAN CODE; WEEKLY RATE BOOK CODE; 
ATTAINED AGE; DURATION; 

CSV_AMOUNT FACTOR; RATE BOOK; ISSUE_AGE; 
DATE LAST MODIFIED; MAINT USER ID 


DB ACCESS DENIAL 


TABLE NAME; DENIAL CD; FORM NAME 


DBACCESSROLE 


ACCESS CD; OBJECT CD; OBJECT ID; ROLE ID; 
MAINT USER ID; DATE LAST MODIFIED 


DB DC RESPONSE PAYEE 


COMPANY_CODE; POLICY NUMBER; 

CLAIM NUMBER; REQUEST TYPE; REQUEST DATE; 

PAYEE ID; PAYEE NAME; ADDRESS LINE 1; 

ADDRESS JJNE_2; ADDRESS LINE 3 ; 

ADDRESS LINE 4; ADDRESS CITY; 

ADDRESS STATE CODE; ADDRESS ZIP CODE; 

TAX ID; TAX ID TYPE; PAYEE TYPE; 

TAX RELATIONSHIP; PERSON BUSINESS 


DB_DC_RESPONSE_POLICY 


COMPANY CODE; POLICY_NUMBER; 

CLAIM NUMBER; REQUESTTYPE; REQUESTDATE; 

ORIGINAL POLICY STATUS; RETURN_CODE; 

INSURED NAME FST; INSURED NAME LST; 

INSURED NAME MID; BILLING FORM; ISSUE__AGE; 

ISSUE DATE; PAID TO DATE; 

MODE OF PAYMENT; MODAL PREMIUM; 

LOAN INDICATOR; SERVICE AGENCY CODE; 

MEDICAL; RATING 2; CHANNEL; 

POLICY CONTROL_STATUS; 

MORTALITY CLASS CODE; LAPSE STATUS; 

LAPSE DATE; AGENT ACCOUNT; PENSION_CODE; 

ELEMENT CODE BASIC; LOB BASIC; 

CLASS CODE BASIC; PLAN CODE BASIC; 

AMOUNT BASIC; REINSURANCE AMOUNT; 

ELEMENT CODE ADB; LOB ADB; 

CLASS CODE ADB; PLAN CODE ADB; 

AMOUNT ADB; ELEMENT CODE RDR1; LOB RDR1; 

CLASS CODE RDR1; PLANCODERDRl; 

AMOUNT RDR1; ELEMENT CODE RDR2; 

LOB RDR2; CLASS CODE RDR2; PLANCODERDR2; 

AMOUNT RDR2; ELEMENT CODERDR3; 

LOB RDR3; CLASS CODE RDR3; PLAN CODE RDR3; 

AMOUNT RDR3; ELEMENT CODERDR4; 

LOB RDR4; CLASS_CODE_RDR4; PLANCODERDR4 ; 

AMOUNTJRDR4; OWNERSHIP CODE; COST_BASIS; 

POLICY LOAN AMOUNT; POLICY_LOAN_DATE; 

INTEREST ON POLICY LOAN; 

MOUNT REFUNDED; PREMIUM REFUND DATE; 

POLICY REINSURED FLAG; OWNER; ASSIGNEE; 

DATE ASSIGNED; AMOUNT_AV AIL ABLE; 

AGENT CODE; AGENT NAME; INSURED_SSN; 

NUMBER OF PAYEES; 

BENEFIT TERMINATION DATE; MATURITY DATE; 
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Table Name 


Variables 




EXPIRY_DATE;FACE_AMOUNT_AT_ISSUE; 
ANNUAL PREMIUM; DATE OF BIRTH; 
INSURED TITLE; ANNUITY FLAG; ISSUE STATE; 
TYPE OF INTEREST; REFUNDSTARTDATE; 
RELATION 


DBERRORS 


PROGRAM ID; PROGRAM RUN USER ID; 
PROGRAM RUN DATE; ERROR LINE SEQUENCE; 
ORACLE ERROR NUM; ORACLE ERROR MSG; 
ERROR DESC; SEVERITY FLAG 


DB_ERROR_MESSAGE_DEF 


ERRORTYPE; ERROR_NUM; ERRORMESSAGE ; 
MAINT_USER_ID; DATE_LAST_MODIFIED; 
USR CODE 


DBMERESPONSEPAYEE 


PAYEE NAME; TAX ID TYPE; TAX ID; 
ADDRESS LINE 1; ADDRESS LINE 2; 
ADDRESS LINE 3; ADDRESS LINE 4; 
ADDRESS CITY; ADDRESS ZIP CODE; 
ADDRESS STATE CODE; COMPANY CODE; 
POLICY NUMBER; REQUEST TYPE 


DBJMERESPONSEPOLICY 


COMPANY CODE; POLICY NUMBER; 

REQUEST TYPE; INSURED NAME; INSURED SEX; 

ISSUE AGE; ISSUE STATE; PENSION CODE; 

BILLING FORM; AGENT ACCOUNT; 

MATURITY DATE; PAID TO DATE; PAIDJUPJDATE; 

POLICY CONTROL STATUS; LOAN INDICATOR; 

SUSPEND INDICATOR; MODE OF PAYMENT; 

SERVICE AGENCY CODE; MODAL PREMIUM; 

CASE1; CHANNEL; LOB BASIC; 

CLASS CODE BASIC; PLAN_CODEjBASIC 

AMOUNT BASIC; POLICY_LOAN_AMOUNT; 

PLAN SHORT NAME; POLICY LOAN DATE; 

LRP DATE; LAPSE CAUSE; 

AMOUNT OF INSURANCE; YEAR_OF_CHANGE; 
DISABILITY PREMIUM; ADB PREMIUM; 
RIDERPREMRJM; RIDER_AMOUNT; 
INTEREST RATE; INTEREST PAID TO YEAR; 
RIDER UNITS; LC ENDOW; ISSUE DATE 


DB_POLICY 


POLICY NUMBER; ISSUE DATE; PAID UP DATE; 
EXPIRY DATE; DATE LAST PAID; PAID_TO_DATE; 
MATURITY DATE; MATURITY YEAR; 
MATURITY REPORTED; POLICY_TYPE; 
DEBIT MODE; INDUSTRIAL FLAG; 
YEAR_OF_CHANGE_DATE; INSURED_CIN; 
VALUATION CLASS; AGENT CODE; 
BENEFICIARY_CIN; APPLICANT_AGE_RANGE; 
EXPIRY YEAR; MATURITY EXPIRY YY; 
CONVERSION_STATUS; D ATE LAST MODIFIED ; 

AyfArVPT J TC C D JT\. AAA TT JT> TTV rVD'DV WW 

MAIN I Uo.bK ID, MAI UKJ1 Y iiAFlKY r i i Y 


DBREPORTDEF 


REPORT ID; DEBIT REPORT NAME; 
MAINT USER ID; DATE LASTJMODIFIED; 
RUN MODE 


DBSCREENDEF 


SCREEN ID; SCREEN NAME; MAINTJUSERJD; 
DATE LAST MODIFIED 


DB_STATE_CODES 


STATE_CODE; STATE_DESC; MAINT_USER_ID ; 
DATE LAST MODIFIED 
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Table Name 


Variables 


DB VERSION 


VERSION NUMBER 


DEBITCLIENT 


CLIENT ID NUMBER; NAME LST; NAME FST; 
NAME MID; TAX ID; DATE LAST MODIFIED; 
MAINTJJSERJD; ADDRESS_LINE_1 ; 

ADDRESS LINE 4; ADDRESSCITY; 
ADDRESS STATE CODE; ADDRESS ZIP CODE 


EXTRATE 


WEEKLY RATE BOOK CODE; RATE BOOK; 
PLAN CODE; DURATION; COSTPERIOD; 
ADDJDAYS; PURE_ENDOW_F ACTOR; 

DATE LAST MODIFIED; MAINT USER ID 


HEALTHPOLICY 


POLICY NUMBER; INSURED YOB; SPOUSE_YOB; 
SPOUSE AGE; HIR CODE; WAIVER 1; WAIVER II; 
HLTH RATE BOOK CODE; 
MARITIAL STATUS;CHANGE IN PREMIUM; 
DATE CHANGED; MOYROLDEST; VJNCREASE; 

rvATC T ACT A/fnnTFTT<r»- AA A INT TTCTJJ? TT"» 
UAlt LASl WlKJDLr LE.IJ, JYlAIiN I (JoilJx IsJ 


LOANAPPROVAL 


POLICY NUMBER; LOAN AMOUNT REQUESTED; 
DATEOFLOAN; EXISTING_LOAN_AMOUNT; 

ITvTTCD CCT L> ATC- T f\A\T TV D f . 

IN 1 bRbo 1 _Jv/\ i LKJ AJN_ 1 i rb, 

APPROVAL_INDICATOR; 

REASON FOR DISAPPROVAL' 

DATE LAST MODIFIED; MAINT USER ID 


LOANBILLING 


POLICY NUMBER; PAYOR_ID_NO; PAYORTYPE; 
START DATE; STOP DATE; DATE LAST MODIFIED; 
MAINT USER ID 


MDO COUPON 


BILLING ACCOUNT NO; BILLING AMOUNT 


MDO_COUPONJBOOK_ 
REQUEST 


POLICY NUMBER; 


PLAN_CODES 


PLAN CODE; WP PLAN CODE; 

PLAN CODE DESC_SHORT; PLAN_CODEJDESC; 

PLAN CODE TYPE; INDUSTRIAL FLAG; TERM IND; 

MATURITY AGE; PAID UP AGE; MAINTJJSERJD; 

DATE LAST MODIFIED; INIT AGE LIMIT; 

INIT VPU; ULTIMATE VPU 


POLICIES_NOT_CONVERTED 


POLICY NUMBER; INSURED NAME; DISTRICT; 
DEBIT; RATE BOOK; PLAN CODE; 
ISSUE DATE CHAR; ISSUE_AGE; 
MODAL PREMIUM; LRP; AGENT CODE; 
REPL PREM; REPL WEEKS; DLP MLP; 
LAPSE CAUSE; AMOUNT OFJNSURANCE; YOC; 
DISABILITY J>REM; ADB J>REM; RIDERPREM; 
RIDER PLAN CODE; INSURED SEX; MEDICAL; 
APPLICANT_AGE_RANGE ; WPADBRATING ; 

ENTEREST YEAR; LOAN AMOUNT; 

MDO VAL_RATING; TERMPNATION_CODE; 

TRANSACTION CODE; OYB INSURED; 

EXPIRY OR MATURITY; NF KIND; 

AMOUNT EXTENDED; YEARS J3XTENDED; 

DAYS EXTENDED; PURE ENDOW AMT; 

PAID UP AMT; FILE OF ORIGIN; OPAI PREMFUM; 
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Table Name 


Variables 




RIDER UNITS; MAINT USER ID; 
DATE LAST MODIFIED 


POLICY_COVERAGE 


POLICY NUMBER; PLAN CODE; 
COVERAGESEQUENCE; INSURED_LEVEL; 
SEX_RELATIONSHIP; MODAL_PREMIUM; 
AMOUNT OF INSURANCE; 

ULTIMATE FACE AMOUNT; UNITS; ISSUE AGE; 
ENSURED NO OF CHILDREN; INSURED YOB; 
RATE BOOK; RATING; PREMIUM REMOVED; 
DESCRIPTION; MDO VALUATION CLASS; 
START DATE; STOP DATE; MAINT USERJD; 
DATE LAST MODIFIED 


POLICY_CSV_TRANSACTION 


POLICY NUMBER; CSV EFFECTIVE DATE; 
DATE LAST PAID; CSV TRANS TYPE; 
LOAN BALANCE ASOF DLP; INTEREST REF DED; 
PREMIUM REF DED; REVERSAL ENTRY_DATE; 
SURRENDER AMOUNT; EXT_TERM_YEAR; 
EXT TERM DAYS; PURE ENDOWMENT; 
REDUCED PAID UP AMT; LAPSE REPORTED; 
DATE LAST MODIFIED ;MAINT USER ID 


POLICY JLOAN 


POLICY NUMBER; INTEREST RATE; 
INTEREST NEXT DUE DATE; 
INTEREST LAST PAIDJDATE; 
INTEREST LAST_ADDED_DATE; 
DATE LAST MODIFIED; MAINT USER ID; 


POLICY LOAN 
TRANSACTION 


POLICY NUMBER; DEBIT TRANS TYPE; 
TRANSACTION_EFF_DATE; INTEREST DUE DATE; 
DATE RECEIVED; MIN INTEREST; 
AMOUNTRECEIVED; TRANSACTIONAMOUNT; 
DESCRIPTION; ADJUST_LOAN_TYPE; 
ACCOUNTING GEN DATE; REVERSAL DATE; 
LAPSE LETTER SENT; BILLING STATEMENT SENT; 
DATE LAST MODIFIED; MAINT USER ID 


POLICYMODALJPREMIUM 


POLICY NUMBER; MODAL PREMIUM; 
START DATE; STOP DATE; REFUND_SEQ_NUMBER; 
COVERAGE SEQUENCE; DATE LAST MODIFIED; 
MAINT USER ID; PAID TO DATE AT CHANGE; 


POLICY_PREMIUM_BILLING 


POLICY NUMBER; BILLING ACCOUNT NO; 
START DATE; STOP DATE; DATE_LAST_MODIFIED; 
MAINT USER ID 


POLICYSTATUS 


POLICY NUMBER; POLICY STATUS; 

DC INFO SENT DATE; START DATE; STOP DATE; 

CAUSE; REFUND JSEQ_NUMBER; PENDFNG_ST ATUS ; 

DATE LAST MODIFIED; MAINT_USER_ID; 

PDUP LETTER SENT; NOTES 


PREMIUMREFUND 


BILLING_ACCOUNT_NO; PAIDTODATE; 
POLICY NUMBER; REFUND START DATE; 
AMOUNT REFUNDED; DATE ENTERED; 
REFUND TYPE; REFUND_SEQ_NUMBER; 
CHECK OR REFUND; DATE LAST MODIFIED; 
MAINT USER ID; PARTIAL PAYMENT REFUNDED 


PREMIUM WAIVER 


POLICY NUMBER; WAIVER START DATE; 
REFUND SEQ NUMBER; WAIVER_STOP_DATE; 
DATE LAST MODIFIED; MAINT USER ID 
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Table Name 


Variables 


PROJECT INFO 


PROJECT CODE: SOLUTION; SITE; PROJECT TYPE 


PTDDATA 


BILLING ACCOUNT_NO; POLICY_NUMBER; 
PAID TO DATE 


STATE COMP 


STATE CODE: STATE STRING 


VALID STATUS CODES 


POLICY STATUS; STATUS DESCRIPTION 


WP PLAN_CODE_ 
CONVERSION 


WP_PLANCODE; PLANCODE; INDUSTRIALFLAG 


W BATCH PAYMENT 


BILLING ACCOUNT NO; CHECK DIGIT; 
DATE PROCESSED; BATCH NUMBER; 
SEQUENCE NUMBER 5; COMPANY_CODE_2; 
PREMIUM_DUE; PREV_AMT_PAID; 
CURR AMT PAID 


W LOAN PAYMENT 


POLICY NUMBER; DATE PROCESSED; 
ANNUAL INTEREST DUE; COMPANY_CODE_2; 
PAID AMOUNT; B ATCH NUMBER; 
SEQUENCE NUMBER 5 


COUNTYTD 


MONTH 1 st DAY; PPAY LIFE MDO; 

PPAY LIFE WP; PPAY HEALTH MDO; 

PPAY HEALTH WP; SURR YTD MDO; 

SURR YTD WP; MAT YTD MDO; MAT_YTD_WP; 

DEATH YTD MDO; DEATH YTD_WP; 

LAPSE YTD LIFE MDO; LAPSE_YTD_LIFE_WP; 

COUNT ETI MDO; COUNT_ETI_WP; 

COUNT RPU MDO; COUNT RPU WP; 

PREM YTD LIFE MDO; PREM_YTD_LIFE_WP; 

PREM YTD HEALTH_MDO; 

PREM YTD HEALTH WP; 

LAPSE YTD HEALTH MDO; 

LAPSE YTD HEALTH WP; 

WAIV REMAINING_MDO; WAIV_REMAINING_WP; 
COUNT PDUPJvlDO; COUNT_PDUP_WP; 
MDO ANNUALIZED PREM; 
WP ANNUALIZED PREM; 
MDO ANNUALIZEDJHLTHJPREM; 
1 WP ANNUALIZED HLTH PREM 



Table II: Batch Programs 



Routine Name 


Input 


Output 


Description 


CALC 
LOAN 
BALANCE 


POLICY_ 
NUMBER 


None 


The CALC_LOAN_BALANCE routine returns the 
loan balance amount for a policy. This routine is used 
intheDB LOAN BILLING MININT, 
DB LAPSE PPAY PRC, DB_NPAY_MININT and 
DB_GENJLOANJTRANS_PRC routines to calculate 
the principal loan balance amount for the policies. 
This routine fetches the loan amount from the 
POLICY_LOAN_TRANSACTION table for a 
particular policy. 


DB CALC_ 
CSV 


POLICY_ 
NUMBER; 


None 


The DB CALC CSV routine returns the cash 
surrender value (CSV) for a policy. The CSV is used 
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Routine Name 


Input 


Output 


Description 




NUMBER 
DATE 




in the DB_LOAN_BILLING_MININT routine to 
check if minimum interest is due and to generate a 
MININT transaction accordingly. This routine 
calculates the cash surrender value by fetching the 
appropriate records from the DB POLICY, 
POLICY COVERAGE and CSVJRATE tables. The 
function returns a value of "-1" in case of any errors 
that occur when running the routine. The 
DBERRORSLOGPRC routine may be used to 
handle the errors generated in the DB_CALC_CSV 
routine. 


DB CALC 
CSV_ON_ 
DATE 


POLICY 
NUM- 
BER; 
DATE 


None 


The DB_CALC_CSV_ON_DATE routine calculates 
the cash surrender value for a policy on a specific date. 
The cash surrender value is used in the 
DB LOAN BILLrNG MINTNT routine to check if 
minimum interest is due and to generate an MININT 
transaction accordingly. This routine calculates the 
cash surrender value by fetching the appropriate 
records from the DB POLICY, 
POLICY_COVERAGE and CSVJRATE tables. The 
function returns a value of "-1" in case of any errors 
generated. The DBERRORSLOGPRC routine 
may be used to handle any errors generated in the 
DB CALC ON CSV function. 


DB DC 

INTERFACE 

PRC 


P 

FILEDIR 
(Directory 
Path) 


None 


The DB JDCJNTERFACE_PRC routine interacts 
with the death claims system 212. More specifically, 
the death claims system 212 creates a file when a death 
claim is filed. On a daily basis, the debit system 202 
checks for the existence of such a file from the claims 
system 212. If present, the 

DB DC INTERFACE PRC routine reads the file and 
generates policy and payee information for the policies 
associated with death claims identified in the file. 
More specifically, for each record in the file, the debit 
system 202 determines what information is required by 
the claims system 212, and then obtains that 
information. For instance, if the death claim system's 
file indicates that a claim is being set up, then the debit 
system 202 calls the 

DB_DC_INT_CLAIM_SETUP_PRC routine 
(discussed below) to change the existing 
POLICY_STATUS to the "DTHF" status. If the death 
claim system's file indicates that the death claim has 
been paid, then the debit system 202 call the 
DB DC JNT_CLAIM_SETTLEJPRC routine 
(discussed below) to changes the POLICY_STATUS 
from "DTHF" to "DTHP." If the death claim system's 
file indicates that the death claim has been deleted, 
then the debit system 202 calls the 
DB_DC_INT__CLAIM_CANCEL_PRC routine 
(discussed below) to delete the DTHF status and 
restore the policy's previous status. The 
DB DC TNTERFACE WRITE PRC routine actually 
generates the policy and payee information required 
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Routine Name 


Input 


Output 


Description 








by the death claims system 212. The 

DB DC INT REQNF PRC routine processes the 

death claim system's request when the identified policy 

is not found in the debit system 202; this prompts the 

system 202 to insert a record in the 

DB DC RESPONSE POLICY table with return code 

"9". 


DB_DC_ 
INT CLAIM_ 
CANCELJPRC 


DC 

REQUEST 

LINE ; 
POLICY 
NUMBER; 
I ERROR 
LINESEQ 

PAR 


0_ 
ER- 
ROR 
LINE 
SEQ 
PAR 


The DB_DC_INT_CLAIM_CANCEL_PRC routine 
cancels the "DTHF" status for the policies associated 
with a death claim that has been deleted. This routine 
is called from the DBDCINTERFACEPRC routine 
(discussed above). That is, the 
DB DC INTERFACE PRC routine reviews the file 
generated by the death claim system's 212 for an 
indication that a death claim has been canceled, and 
then passes the policy associated with such a claim to 
the DB_DC_rNT__CLAIM_CANCEL_PRC routine. 
This routine deletes the "DTHF" status of the policy 
associated with a cancelled death claim in the 
POLICY STATUS table and activates the previous 
status for the policy. This routine also updates the 
STOP DATE field of the POLICY STATUS table. 


DB DC INT 
CLAIM_ 
SETTLE_ 
PRC 


DC 

REQUEST 
LINE; 
POLICY 
NUMBER; 
I ERROR_ 
LINE 
SEQ 
PAR 


O 

ER- 
ROR 
LINE 
SEQ 
PAR 


The DB DC INT CLAIM SETTLE PRC routine 
changes the "DTHF" (Death Claim Filed) status to the 
"DTHP" (Death Claim Processed) status in the 
POLICY STATUS table for the policies associated 
with settled death claims. This routine is called from 
theDB DC INTERFACE PRC routine (discussed 
above). That is, the DBDCINTERFACEPRC 
reviews the file generated by the death claim system 
212 for an indication that a death claim has been 
canceled, and then passes such a claim to the 
DB DC INT CLAIM SETTLE PRC routine. This 
routine changes the status in the POLICY_STATUS 
table from "DTHF" to "DTHP." This routine also 
updates the STOP DATE field to the current date - 1 . 
This routine also checks for any PAYPRM 
transactions (premium payments) received for the 
policy after the death claim has been filed. The system 
refunds all such transactions by inserting an 
appropriate record in the PREMIUM REFUND table. 


DB DC INT_ 
CLAIM 
SETUP PRC 


DC 

REQUEST 

LINE; 
POLICY 
NUMBER; 
I ERROR 
LINE SEQ 

PAR 


0 

ER- 
ROR 
LINE 
SEQ 
PAR 


The DB_DC_INT_CLAIM_SETUP_PRC routine 
fetches the details of policies associated with a new 
claim setup and inserts appropriate records in the 
DB_DC_RESPONSE_POLICY table. More 
specifically, the following tables are queried to fetch 
the policy details: DEBIT_CLIENT; 
POLICY MODAL PREMIUM; 
POLICY COVERAGE; POLICY STATUS; 
DB POLICY; POLICY_LOAN_TRANSACTION; 
and POLICY_COVERAGE. This routine further 
changes the status of the policies to "DTHF." And if 
the current POLICY STATUS is "DTHF," then this 
routine updates the DC INFO SENT DATE field of 
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Routine Name 


Input 


Output 


Description 








the POLICY COVERAGE table. This routine is 
called from the DBDCINTERFACEPRC routine, 
which examines the file generated by the death claim 
system 212 for an indication of new claim setups. 


DB DC_INT_ 
REQNFPRC 


DC 

REQUEST 

LINE; 
I ERROR 
LINE SEQ 

PAR 


O 

ER- 
ROR 

LINE 
SEQ 
PAR 


The DB DC INT REGNFPRC routine inserts a 
record into the DB_DC_RESPONSE_POLICY table 
when the requested policy details are not found in the 
debit system 202. This routine is called from the 
DB DC INTERFACE_PRC routine. That is, the 
DB DC INTERFACE_PRC routine examines the file 
generated by the death claim system 2 12. If the file 
identifies policy information that is not found in the 
debit system 202, then the 

DB DC INT REGNF PRC routine inserts a record in 
the DB DC_RESPONSE_POLICY table with return 
code "9." 


DB_DC_ 
INTERFACE_ 
WRITE PRC 


P 

FILEDIR 
(Directory 
Path) 


None 


The DBDCINTERFACEWRITEPRC routine 
generates the policy and payee flat files, namely 
DC DEBIT POLICY.TXT and 
DC DEBIT PAYEE.TXT, respectively, for the death 
claims system 212. More specifically, this routine 
collects the requested policy and payee information 
from the DB DC RESPONSE_POLICY and 
DB DC RESPONSE PAYEE tables, respectively, 
and then generates the DC_DEBIT__POLICY.TXT and 
DC DEBIT PAYEE.TXT flat files which are sent to 
the death claims system 212. This procedure is called 
from the DB DC INTERFACE PRC routine. 


DB DC ME_ 
RESP READ_ 
PRC 


P 

FILEDIR 
(Directory 
Path) 


None 


The DB DC ME RESP READ_PRC reads the 
interface file "DC_ME_LAPSES.TXT" generated by 
the matured endowments system 214 and updates the 
POLICY STATUS table for policies having settled 
maturity and lapsed death claims statuses. This routine 
calls the DB DC_ME_RESP_UPD_PRC routine to 
close the "MATF" status of the policies identified in 
the DC ME_LAPSES.TXT". That is, this routine 
changes the "MATF" status (maturity filed) to the 
"MATP" status (maturity paid) in the 
POLICY STATUS table. 


DB DC ME 
RESP_UPD_ 


DC 

REQUEST 

LINE; 
POLICY_ 
NUMBER; 
I ERROR 
LINEJSEQ 

PAR 


0 

ER- 
ROR 

LINE_ 

SEQ 

PAR 


The DB DC_ME_RESP_UPD_PRC routine closes 
the "MATF" status and inserts the "MATP" status in 
the POLICY_STATUS table for policies having 
settled maturity and lapsed death claims. But the 
"MATP" status is inserted for a policy only if the 
previous status is "MATF." This routine also updates 
the STOP DATE field of the POLICY_STATUS 
table. This routine is called from the 
DB DC ME_RESP_READ_PRC routine (discussed 
above). 


DB ERRORS_ 
LOG_PRC 


None 


None 


The DB ERRORS LOG PRC routme logs the errors 
that occur in the course of running the debit system's 
routines. More specifically, this routine logs details 
such as program ID, error line, oracle error number, 
oracle error message, etc. in the DB ERRORS table. 
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Routine Name 


Input 


Output 


Description 


DBGENACC 
EXTRACT 


P_ 

FILEDIR 


None 


The DBGENACCEXTRACT routine generates the 
accounting extract file "EXTRACT.TXT" for "WP" 
and "MDO" debit modes. More specifically, this 
routine fetches the records from the DB POLICY and 
POLICYLOANTRANSACTION tables for "WP" 
and "MDO" debit modes and generates the extract file 
"EXTRACT.TXT." The routine also updates the 
POLICY LOAN TRANSACTION table to set the 
ACCOUNTING GEN DATE to the current date. 


DB 

GEN_ 
LOAN 
TRANPRC 


None 


None 


The DBGENLOANTRANPRC routine creates 
TRMNTD loan transactions for all the revived or 
lapsed policies. This routine fetches the records from 
POLICY_STATUS and 

POLICY LOAN TRANSACTIONS tables having 
STOPDATE = STARTDATE - 1 and 
POLICY_STATUS "IN" (e.g., ETI, RPU, SURR, 
LPNVL, DTH, MATP) and insert records into the 
POLICY JJ3ANTRANSACTIONS table. The 
DB ERRORS PRC routine handles all of the errors. 


DB HEALTH 

MATEXPR 

PRC 


None 


None 


The DBHEALTHMATEXPRPRC program 
identifies the health policies about to expire and 
changes the status in the POLICY_STATUS table. 
More specifically, this routine looks for health policies 
that will expire within the coming calendar month (that 
is, the EXPIRYDATE of the policy is within the 
coming calendar month). On finding such a policy, the 
routines builds a policy status record of "EXPIR" with 
STARTJDATE = EXPIRYDATE + 1 day, and builds 
a PPAY status record with SET STOP on the 
EXPIRY DATE. The DBERRORSLOGPRC 
routine handles all of the errors. 


DB INVALID 
BILL ACC 
PRC 


None 


None 


The DB_INVALID_BILL_ACC_PRC routine sets 
ACCOUNT_STATUS to "I" if the account is invalid. 
More specifically, this routine examines all records in 
the BILLING ACCOUNT table in which 
ACCOUNTJSTATUS = "A" (Active). The routine 
then locates any accounts where one of the following 
situations exists, and then sets the 
ACCOUNT STATUS to "I" (Inactive or Invalid): (1) 
there is no current PRIMARYPAYER attached to the 
account (where there normally should be a 
BILLrNG_ACCOUNT_PAYER table record 
indicating that PAYOR TYPE = "P" and the current 
system date is between START DATE and 
STOP DATE); (2) there is a policy attached to the 
account that has status "PPAY," but does not have a 
current POLICYMODALPREMIUM table record 
(where there normally should be a record indicating 
that every premium paying policy has a 
POLICY_MODAL_PREMIUM record with current 
system date between STARTJDATE and 
STOP DATE); (3) there are no policies currently 
attached to the account in the 
POLICY PREMIUM BILLING table (where there 



41 



Attorney Docket No. 52493.000121 



Routine Name 


Input 


Output 


Description 








should be at least one POLICY JPREMIUM 

BILLING table record with 
BILLING_ACCOUNTNO equal to the billing 
account, where current system date is between 
START_DATE and STOP_DATE. The 
DB ERRORS LOGPRC routine handles all errors. 


DB LAPSE 
_PPAY 


None 


None 


The DBLAPSEPPAY routine identifies the 
premium paying policies having PAIDTODATE > = 
90 past due, where account status is "A." On finding 
such a billing account, this routine determines if there 
are still policies attached to it with POLICYJSTATUS 
= "PPAY." If so, this billing account and its policies 
are lapsed. 


DB 

LIFE MATEX 
PRPRC 


None 


None 


The DB LIFE MAEX PR PRC program identifies 
the policies about to mature or expire and changes the 
status in the POLICY_STATUS table to reflect this 
event. More specifically, this routine examines the 
data storage every month end to determine policies that 
will mature or expire in approximately 30 days. On 
finding a policy that will mature, the debit system: (1) 
closes out the current POLICY STATUS record by 
setting STOPDATE equal to MATURITYJDATE - 1 
day; (2) builds a new POLICYSTATUS record with 
status = "MAT"; (3) sets START DATE equal to 
MATURITYJDATE; (4) sets PENDING STATUS on 
the MAT_POLICY_STATUS record to "P" to indicate 
that the debit system has not yet been notified that the 
maturity has either been paid out or been escheated; 
and (5) generates an interface extract record for the 
claims system, which is written to a file that will be 
read by the claims system so that a claim can be set up. 
On finding a policy that will expire, the debit system: 
(I) closes out the current POLICY_STATUS record 
by setting the STOP DATE equal to EXPIRY DATE 
- 1 day; and (2) builds a new POLICY STATUS 
record with STATUS = "EXPIR." 


DB LOAN 
MININT 


None 


None 


The DB LOAD MININT program searches the 
POLICY LOAN table looking for PPAY, WAIV, 
PDUP or PUE policies for loans with INTEREST_ 
NEXTJDUEDATE occurring within the next 6 
weeks. On finding such a loan, the routine: (1) 
computes annual interest; (2) generates an ADDINT 
transaction; (3) computes CSV and determines if 
minimum interest is due (and if it is, the routine 
generates a MININT transaction); and (4) updates the 
POLICY_LOAN record, setting INTEREST_NEXT_ 
DUE DATE to its previous value + 1 year. 


DB LOAN 
PKG 


None 


None 


The DB LOAN PKG program processes the batch 
payments coming from the bank(s) and inserts into the 
BILLING ACCOUTSTT TRANS table indications of 
matching and non-matching payments. More 
specifically, this routine: (1) sorts bank batch files 
containing premium and loan payments for the debit 
system; (2) combines the batch information with detail 
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Routine Name 


Input 


Output 


Description 








records; (3) detects matching and non-matching 
payments; (4) creates PAYINT records and updates 
MININT records as appropriate; and (5) produces a 
loan interest collection report. 


DB ME 

INTERFACE 

PRC 


date; 
file DIR 


None 


The DB_ME_INTERFACE_PRC routine creates an 
interface file for the matured endowments system 214. 
The routine fetches values from the tables 
DEBIT CLIENT, POLICY LOAN, 
POLICY MODAL PREMIUM, 
POLICYCOVERAGE, POLICY_STATUS, and 
DB POLICY, and inserts information into the 
DB ME RESPONSE table. It also insert records into 
POLICY_STATUS and 

DB_ME_PAYEE_RESPONSE tables. It then writes 
different values into the interface file. 


DB NPAY 
MININT 


None 


None 


The DB NPAY MININT program identifies the 
policies with minimum interest due. More specifically, 
this routine looks for any MININT policy loan 
transaction where the ANNUAL_INTEREST_DUE 
DATE is 30 or more days overdue and the transaction 
amount is equal to 0. On finding such a transaction, 
the routine checks if the status of the associated policy 
is still PUE, WAIV, or PDUP. It then sets the 
STOP DATE of that POLICY STATUS record to the 
ANNUAL JTNTERESTJDUE_DATE - 1 day. 
Further, this routine builds a new POLICY_STATUS 
record having status = LPNVL. The routine also sets 
the START DATE of the new record to the 
ANNUAL_INTERESTJDUE_DATE. It also creates 
a POLICY CSV TRANSACTION record with 
EXTENDED AMOUNT = 0 and a 
TRANSACTION TYPE of "E." The routines also 
computes the CSC_AMOUNT from 
LOAN BALANCE minus the 
MINIMUM INTEREST AMOUNT. The 
DB ERRORS LOG PRC routine handles all errors. 


DB PAYMENT 
_PKG 


None 


None 


The DBPAYMENTJPKG routine processes 
notification of payments coming from the bank(s) and 
inserts into BILLING_ACCOUNT_TRANS table 
indications of matching and non-matching payments. 
More specifically, this routine: (1) detects matching 
and non-matching payments; (2) creates PAYPRM 
records and HLDPRM records as appropriate; (3) 
produces a premium payments listing; (4) generates 
acknowledgement letters for matching payments; and 
(5) if a payment takes a policy to its 
PAIDUPDATE, closes out the PPAY 
POLICY STATUS record (e.g., sets STOP DATE to 
PAID UP JDATE - 1 day) and creates a PDUP 
POLICY_STATUS record (e.g., sets STARTJDATE 
to PAID UPDATE). This package consists of the 
following routine: DB PAYMENT PROCESS; 
DB PROCESS PPB;DB MATCHING CHECK; 
DB PROCESS MISMATCH; 
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Routine Name 


Input 


Output 


Description 








DB PROCESS MATCHING; and 

DB UPDATE_POLICY_STATUS. The 

DB ERRORS LOG PRC routine handles all errors. 


DB PAYMENT 
PROCESS 


None 


None 


The DB PAYMENT PROCESS routine performs the 
initial checking for the validity of the billing record. 
Checking is performed by comparing a check digit sent 
by the bank(s) with a check digit maintained by the 
debit system. Mismatches are logged in the error file. 
A billing account is valid if it exists in the 
BILLING ACCOUNT table, and is indicated as 
having an active, "A," status. 


DB_PROCESS_ 
PPB 


None 


None 


This routine retrieves valid policy numbers to be 
included in the total modal premium. 


DB 

MATCHING_ 
CHECK 


None 


None 


This routine checks whether the total amount received 
is a whole multiple of the total modal premium 
amount. 


DB PROCESS_ 
MISMATCH 


None 


None 


This routine processes non-matching records. 


DB PROCESS_ 
MATCHING 


None 


None 


This routine performs the main processing for 
matching records. 


DB UPDATE 

POLICY 

STATUS 


None 


None 


The DB UPDATE POLICYSTATUS routme 
updates the POLICY STATUS to PDUP if the policy 
has become PDUP (paid up). 


DB WAIV 

PTD 

UPDATE 


None 


None 


The DB WAIV_PTD_UPDATE routine updates the 
waiver records paid to date. More specifically, this 
routine detects any policies on waiver (e.g. current 
POLICY STATUS = "WAIV") where the 
PAID TO_DATE field should be updated. If the 
PAIDTODATE field on a WP policy is equal to or 
less than the current processing date, the routine 
bumps the PAID_TO_DATE on the POLICY table up 
by 1 week (normally this will happen on Monday 
night, since WP PAID_TO_DATES occur on 
Mondays). If this policy is attached to a billing 
account with no premium paying policies, then the 
routine also bumps the PAID TO DATE on this 
billing account. If the PAIDTODATE on an MDO 
policy is equal to or less than the current processing 
date, the routine bumps the PAID TO DATE on the 
POLICY table up by 1 month. If the policy is attached 
to a billing account with no premium paying policies, 
the routine also bumps up the PAID_TO_DATE on 
this billing account. The DB_ERRORS_LOG_PRC 
routine handles all errors. 


DB 

MONTHLY 
COUNTS 


D INPUT 
DATE 


None 


The DB MONTLY COUNTS routme maintains 
various counts in the COUNT_YTD table for "next 
month" relative to the input date. More specifically, 
the first day of the next month relative to the input date 
is computed and the counts are calculated for this first 
day of the next month. Some of the counts that are 
computed include: (1) number of premium paying life 
policies with MDO and WP debit modes; (2) number 
of premium paying health policies with MDO and WP 
debit modes; (3) number of life policies with MDO 
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Routine Name 


Input 


Output 


Description 








and WP debit modes in waiver state; (4) the total 
premium payment amount for the PAYPRM 
transactions for MDO and WP debit modes; (5) 
number of policies of extended term insurance type 
(ETI) with MDO and WP debit modes; (6) number of 
policies of reduced paid up (RPU) type with MDO and 
WP debit modes; (7) number of policies surrendered 
with MDO and WP debit modes; (8) number of 
policies with death claim processed (DTHP) having 
MDO and WP debit modes; (9) number of policies 
with matured endowment processed (MATP) having 
MDO and WP debit modes; (10) number of lapsed life 

of paid up policies with MDO and WP debit modes; 
(12) total annual premium for premium paying life 
policies with MDO and WP debit modes; and (13) 
total annual premium for health policies with MDO 
and WP debit modes. Depending 
on the above-identified count values, various fields of 
the COUNT YTD table are updated. 



Table III: Batch Reports 



Name 


Frequency and 
Criteria 


Tables 
Accessed 


Description 


15 Day 


Frequency: 


DEBIT 


The 15 Day Lapse Notice Report identifies 


weekly. 


CLIENT; 


polices having delinquent payments (meeting 


Lapse 
Notice 


Criteria: 


POLICY 


the 1 5 day lapse notice criteria). Detailed 


DEBIT 


LOAN 


Information in this report includes: debit client 


DB_RPT27 


TRANS TYPE = 


TRANS- 


information (CLIENTJD_NUMBER; 




"MLNINT"; 


ACTION 


LAST NAME; ADDRESS_LINE_1; 




LAPSE 




ADDRESS LINE 2; ADDRESS LINE 3; 




LETTER SENT 




ADDRESS LINE_4; ADDRES S ST ATE_ 




= "N"; 




CODE; ADDRESS_ZIP_CODE); policy loan 




POLICY 




transaction information (POLICY NUMBER; 




STATUS = 




INTEREST DUE DATE; 




"PPAY." 




TRANSACTION_AMOUNT). Input 
Parameters include: P 1;DUE DATE. 


Acknow- 
ledgement 
Letter 


Frequency: 


POLICY 


The Acknowledgment Letter Report generates 


weekly. 


STATUS; 


acknowledgement letters. Detailed information 


Criteria: 


POLICY 


in this report includes: 


PAYOR 


PREMIUM 


billing account transaction information 


DBRPT32 


TYPE = "P"; 


BILLING; 


(BILLING ACCOUNT NUMBER; 




POLICY 


POLICY 


PREMIUM PAYMENT_AMOUNT; 




STATUS is 


MODAL 


PARTIAL PAYMENT; 




"PPAY" or 


PREMIUM; 


PAYMENT_APPLIED_FLAG); billing 




"DTHF"; 


BILLING 


account payor information 




DEBIT_ 


ACCOUNT 


(PAYOR ID NUMBER; PAYOR TYPE); 




MODE = "WP"; 


PAYOR; 


POLICY PREMIUM BILLING NUMBER; 




PAYMENT 


DB 


POLICY_STATUS; 




APPLIED 


POLICY; 


POLICY_MODAL PREMIUM; DB policy 




FLAG = "Y"; 


BILLING 


information (POLICY TYPE; DEBIT MODE; 
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Name 


Frequency and 
Criteria 


Tables 
Accessed 


Description 




ACK 
LETTER 
SENT = "N"; 
DEBIT 
TRANS 
TYPE = 
"PAYPRM" 


ACCOUNT 
_TRANS 


INSURED CIN). Input parameters include: 
REPID; REP NAME. 


Bank 

Payment 

Messages 

DB_RPT57 


Frequency: 

daily. 

Criteria: 

PROGRAM ID = 
DB PAYMENT 
PKG 


DB 

ERRORS 


The Bank Payment Messages Report generates 
information indicating the results of processing 
of payments received from the bank(s). 
Detailed information presented in this report 
includes: DB errors information (PROGRAM 
ID; PROGRAM JRUNJDATE; ERROR_ 
DESC). Input parameters include: REP ID; 
REP NAME. 


HLDPRMs 
Listing 

DBJRPT52 


Frequency: 

daily. 

Criteria: 

DEBIT TRANS 
TYPE = 
"HLDPRM" 


BILLING 

ACCOUNT 

_TRANS 


The HLDPRMs Listing Report lists the 
HLDPRM transactions for the billing accounts. 
Detailed information presented in this report 
includes: billing account transaction 
information: BILLING ACCOUNT 
NUMBER; DATE RECEIVED; AMOUNT_ 
RECEIVED). Input parameters include: none. 


Health 
Policy Due 
To Expire 
In The Next 
Calendar 
Month 
DBRPT46 


Frequency: 

monthly. 

Criteria: 

POLICYJTYPE 
= "P"; 

EXPIRYDATE 
between 
START DATE 
and ENDDATE 


DB 

POLICY; 
POLICY 
STATUS 


This report identifies health policies due to 
expire in the next calendar month. Detailed 
information presented in this report includes: 
DB Policy Information (POLICY NUMBER; 
EXPIRY DATE; DEBITMODE) ; 
policy status information (POLICY STATUS; 
START DATE). Input parameters include: 
START DATE; END_DATE; 
SYS MAX DATE; MONTH. 


Inforce 
Policies Due 
To Mature 
In The Next 
Calendar 
Month 

DBRPT43 


Frequency: 

monthly. 

Criteria: 

POLICY 

STATUS = 

"PDUP," 

"WAIV," 

"PPAY," 

"DTHF"; 

MATURITY_ 

DATE between 

START DATE 

and END DATE 


DB 

POLICY; 
POLICY 
STATUS 


This report identifies in force policies due to 
mature in the next calendar month. Detailed 
information presented in this report includes: 
DB policy information (POLICY NUMBER; 
MATURITY JDATE; DEBITMODE) ; policy 
status information (POLICY_STATUS; 
START DATE). Input parameters include: 
AS_OF_DATE. 


Lapsed 
Policies Due 
To Expire 
In The Next 
Calendar 
Month 
DBRPT47 


Frequency: 
monthly. 
Criteria: 
POLICY 
STATUS = 
"ETI," "DTHF"; 
EXPIRY JDATE 
between 


DB 

POLICY 
POLICY 
STATUS 


This report identifies lapsed policies due to 
expire in the next calendar month. Detailed 
information presented in this report includes: 
DB policy information (POLICY NUMBER; 
EXPIRYDATE; DEBITMODE); policy 
status information (POLICY_STATUS; 
START DATE). Input parameters include: 
AS OF DATE. 
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Name 


Frequency and 
Criteria 


Tables 
Accessed 


Description 1 




START DATE 
and END DATE 






Lapsed 
Policies Due 
To Mature 
In The Next 
Calendar 
Month 
DB_RPT44 


Frequency: 
unknown. 
Criteria: 
POLICY 
STATUS should 
be in "ETL" 
"RPU," "PUE" or 
"DTHF"; 
MATURITY_ 
YEAR between 
STARTDATE 
and END DATE 


DB 

POLICY 

POLICY_ 

STATUS 


This report identifies lapsed policies due to 
mature in the next calendar month. Detailed 
information presented in this report includes: 
DB policy information (POLICY_NUMBER; 
MATURITY DATE; DEBIT MODE); policy 
status information (POLICY^STATUS; 
STARTDATE). Input parameters include: 
REPORTDATE. 


Loan 

Billing 

Statement 

DBRPT30 


Frequency: 

weekly. 

Criteria: 

PAYORTYPE = 
"P"; 

DEBIT TRANS 
TYPE 

="ADDINT"; 
BILLING, 
STATEMENT, 
SENT o "Y" 


DEBIT_ 
CLIENT; 
LOAN 
BILLING; 
POLICY_ 
LOAN; 
POLICY 
LOAN 
TRANS- 
ACTION 


This report presents loan billing statements. 
Detailed information presented in this report 
includes: POLICY_NUMBER; NAME; 
ADDRESS. Input parameters include: none 


Loan 

Interest 

Collection 

DB_RPT16 


Frequency: 
daily. 
Criteria: 
none. 


W 

LOAN_ 
PAYMENT 


This report displays the loan interest details for 
the policies. Detailed information presented in 
this report includes: POLICY NUMBER; 
SEQUENCE NUMBER; BATCH NUMBER; 
INTEREST DUE; MINIMUM_INTEREST 
DUE; CURRENTJNTEREST_PAID. Input 
parameters include: none 


Loan 

Payment 

Report 

DB_RPT11 


Frequency: 
on request. 
Criteria: 

DEBIT_TRANS_ 

TYPE in 

"PAYTNT," 

"PAYPRIN," 

"UNERNINT," 

"REFPRIN," 

"ADDINT," 

"NEWTNT," 

"MININT"; 

DEBITMODE 

in "MDO," "WP" 


DB 

POLICY; 
POLICY 
LOAN_ 
TRANS- 
ACTION. 


This report generates information on loan 
payment. Detailed information presented in 
this report includes: POLICYJNUMBER; 
DATE EFFECTED; DATE__RECEIVED; 
TRANSACTION TYPE; 
TRANSACTION_AMOUNT. Input 
parameters include: START DATE; 
ENDDATE. 


Loan 
Payoff 
Without 
Refund 

DBRPT31 


Frequency: 
undefined. 
Criteria: 
STOPDATE = 
given date, e.g., 
"12/31/2099"; 
PAYOR TYPE = 


DEBIT_ 
CLIENT 


This report prints out the loan payoff letters for 
the selected policies, stating that the policy 
loans have been paid off. Detailed information 
presented in this report includes: CURRENT_ 
DATE; POLICY CLIENTJNAME; CLIENT_ 
ADDRESS; POLICY_NUMBER; FNSURED_ 
NAME; Letter Content (stating that the loan 



47 



Attorney Docket No. 52493.000121 



Frequency and 
Criteria 



Tables 
Accessed 



Description 



has been paid off in full). Input parameters 
include: POLICY NUMBER. 



MDO 
Coupon 
Book 
Listing 



Frequency: 


DEBIT_ 


undefined. 


CLIENT 


Criteria: 


POLICY 


ACCOUNT 


MODAL 


STATUS = "A"; 


PREMIUM 


PAYOR TYPE = 


POLICY 


"P"; 


PREMIUM 


POLICY 


BILLING 


STATUS = 


BILLING 


"PPAY"; 


ACCOUNT 


DEBIT MODE = 


PAYOR 


"MDO"; 


BILLING 


NEXT COUPON 


ACCOUNT 


BOOK DATE 




<= SYSDATE + 




59; 




PAYOR TYPE = 





This report prints the billing account details 
having NEXT_COUPONJBOOK_DATE 
within two months previous to the current date. 
Detailed information presented in this report 
includes: BILLING_ACCOUNT_NUMBER; 
PAIDDATE; NAME; COUPON_DATE. 
Input parameters include: none. 



MDO 

Coupon 

Request 



Frequency: 


DEBIT 


weekly. 


CLIENT; 


Criteria: 


POLICY 


ACCOUNT 


MODAL 


STATUS = "A"; 


PREMIUM; 


PAYOR TYPE = 


POLICY 


"P"; 


PREMIUM 


POLICY 


BILLING; 


STATUS = 


BILLING 


"PPAY"; 


ACCOUNT 


DEBIT MODE = 


PAYOR; 


"MDO"; 


BILLING_ 


NEXT COUPON 


ACCOUNT; 


BOOK DATE 


POLICY 


<= TRUNC 


STATUS 


((SYSDATE) + 




59); 




PAYOR TYPE = 
"P" 




Frequency: 


DEBIT 


weekly. 


CLIENT 


Criteria: 


POLICY ST 


DEBIT TRANS 


ATUS 


TYPE = 


LOAN BIL 


"MININT"; 


LING 


INTEREST DUE 


POLICY L 


DATE > 


OAN TRA 


TRUNC(AS OF 


NSACTION 


DATE-5) + 35; 




INTEREST DUE 




DATE <= 




TRUNC(AS OF 




DATE -5) + 42; 





This report prints the billing account details 
having NEXT_COUPON_BOOK_DATE 
within two months previous to the current date. 
Detailed information presented in this report 
includes: BILLING ACCOUNT NUMBER; 
POLICY NUMBER; PAID DATE; 
LAST NAME; ADDRESS_LINES 1-4; CITY; 
STATE CODE; ZIP_CODE; 
COUPONjDATE; PAYOR_ID__NUMBER; 
MODAL PREMIUM. Input parameters 
include: BILLING_ACCOUNT_NUMBER; 
BILLING ACCOUNT; COUPON__BOOK_ 
DATE. 



Minimum 
Interest 
Notice For 
Waiver 

DBRPT28 



This reports presents information pertaining to 
minimum interest for waivers. Detailed 
information presented in this report includes: 
CURRENTDATE; POLICY_CLIENT_ 
NAME; CLIENT ADDRESS; POLiCY_ 
NUMBER; INSURED NAME; MINIMUM, 
POLICY JLOANJNTERESTJXJEJDATE; 
Letter Content (stating that the amount of 
minimum loan interest must be paid within 3 1 
days of the interest due date or policy will 
lapse). Input parameters include: 
AS_OF DATE. 
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Name 


Frequency and 


Tables 


Description 




Criteria 


Accessed 






POLICY 








STATUS = 








"WAIV"; 








PS_POLICY_ 








STATUS= 








"DTHF" and 








PREVIOUS 








POLICY 








STATUS = 








"WAIV" 






Minimum 


Frequency: 


DEBIT 


This report provides letters stating that the 


Premium 


weekly. 


CLIENT; 


minimum loan interest must be paid within 3 1 


Due For 


DEBIT TRANS_ 


POLICY 


days of the interest due date or the policy will 


Premium 


TYPE = 


LOAN_ 


lapse. Detailed information presented in this 


Paying 


"MININT"; 


TRANS- 


report includes: debit client information 


Policies 


INTERESTDUE 


ACTION ; 


(CLIENT_ IDJNUMBER; LAST_NAME; 


DB RPT29 


_DATE between 


LOAN BIL 


ADDRESS_ LINE_1 ; ADDRESS_LINE2; 


32 and 45 days 


LING; 


ADDRESS LINE 3; ADDRESS JLINE_4; 




from 


POLICY_ 


ADDRESS STATE CODE; 




AS OF DATE; 


STATUS 


ADDRESS_ZIP_CODE); 




POLICY_ 




policy loan transaction information (POLICY_ 




STATUS in 




NUMBER; INTEREST DUE DATE). Input 




"PPAY," 




parameters include: AS_OF_DATE. 




"PDUP," "PUE," 








"DTHF" 






New 


Frequency: 


DB 


This report provides new account notice letters. 


Account 


not defined. 


POLICY; 


Detailed information presented in this report 


Notice 


Criteria: 


BILLING 


includes: billing account information 


Letter 


PAYORTYPE 


ACCOUNT 


(BILLING ACCOUNTNUMBER; 


="P"; 


PAYOR; 


PAID TO DATE); DB policy information 


DB_RPT08 


DEBITMODE = 


POLICY_ 


(POLICYJTYPE; DEBIT MODE; 




"WP"; 


STATUS; 


INSURED CIN); billing account payor 




POLICY 


POLICY 


information (PAYORIDNUMBER; 




STATUS = 


MODAL_ 


PAYOR TYPE); policy premium billing 




"PPAY" 


PREMIUM; 


information (POLICY NUMBER); 




POLICY_ 


POLICY STATUS; MODAL_PREMIUM. 






PREMIUM 


Input parameters include: REP_ID; 






BILLING; 


REPNAME. 






BILLING 








ACCOUNT. 




Notice of 


Frequency: 


DB 


This reports provides notice of lapsed MDO 


Lapsed 


weekly. 


POLICY; 


premium due. Detailed information presented 


MDO 


Criteria: 


BILLING 


in this report includes: billing account 


Premium 


POLICY_ 


ACCOUNT 


information 


Due 


STATUS = 


PAYOR; 


(PARTIAL PAYMENT_BALANCE); DB 




"PPAY"; 


POLICY_ 


policy information (POLICYJTYPE; 


DB_RPT24 


DEBITMODE = 


STATUS; 


DEBIT MODE; INSURED_CrN); billing 


"MDO"; 


BILLING 


account payor information (PAYOR_TYPE); 




PAYMENTAPP 


ACCOUNT 


policy premium billing information 




LIED FLAG = 


TRANS; 


(POLICY NUMBER); policy status 




"Y"; 


POLICY_ 


information (POLICY_STATUS; 




LATE NOTICE_ 


PREMIUM 


START DATE); billing account transaction 




SENT ="N" 


BILLING; 


information 
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Name 


Frequency and 
Criteria 


Tables 
Accessed 


Description 






BILLING 
ACCOUNT; 
DEBIT_ 
CLIENT 


(BILLING ACCOUNT NUMBER; PAID_ 
TODATE; 

PREMIUM PAYMENT AMOUNT; 
PAYMENTAPPLIEDJFLAG); debit client 
information (ADDRESS LINE 1; 
ADDRESS LINE 2; ADDRESS LINE 3; 
ADDRESS LINE 4; ADDRESS CITY; 
ADDRESSSTATECODE; 
ADDRESS ZIP CODE). Input parameters 
include: REP ID; REP NAME. 


Notice Of 

Lapsed 

Weekly 

Premium 

Due 

DBJRPT25 


Frequency: 
weekly. 
Criteria: 
POLICY 
STATUS = 
"PPAY," 
"DTHF"; 
DEBIT MODE = 
"WP"; 
PAYMENT 
APPLIED FLAG 
= "Y"; 

LATE NOTICE 
SENT = "N" 


DB 

POLICY; 

BILLING_ 

ACCOUNT 

PAYOR; 
POLICY 
STATUS; 
BILLING 
ACCOUNT 

TRANS; 
POLICY_ 
PREMIUM^ 
BILLING; 
BILLING 
ACCOUNT; 
DEBIT_ 
CLIENT. 


This report provides notice of lapsed weekly 
premiums due. Detailed information presented 
in this report includes: billing account 
information 

(P ARTIAL P AYMENT B ALANCE) ; DB 
policy information (POLICY JTYPE; 
DEBITMODE; INSURED CIN; 
PAIDUPDATE); billing account payor 
information (PAYOR TYPE); policy premium 
billing information (POLICYNUMBER); 
Policy status information (POLICYSTATUS; 
STARTJ3ATE) billing account transaction 
information 

(BILLING ACCOUNT JSPUMBER; PAID_ 
TO DATE; 

PREMIUMPAYMENTAMOUNT; 

P A YMENT_APPLIEDJFLAG) ; debit client 

information (LAST NAME; 

ADDRESS LINE 1; ADDRESS LINE 2; 

ADDRESS LINE 3; ADDRESS LINE 4; 

ADDRESS CITY; 

ADDRES S STATE CODE; ADDRESS_ 
ZIP CODE). Input parameters include: 
REPORT ID; REPORT NAME. 


PAYINIT 
Transac- 
tions - Not 
Applied 

DB_RPT59 


Frequency: 
not defined. 
Criteria: 

DEBIT TRANS 
TYPE= 
"PAYINT"; 
TRANSAC- 
TION AMOUNT 
= 0 


POLICY_ 
LOAN 
TRANS- 
ACTION; 


This report identifies PAYINIT transactions not 
applied. Detailed information presented in this 
report includes policy loan transaction 
information, including: POLICY NUMBER; 
DEBIT TRANSACTION TYPE; 
DATE RECEIVED; AMOUNT RECEIVED; 
TRANSACTIONAMOUNT. Input 
parameters include: none. 


Policies 
Lapsed For 
Non- 
payment Of 
Premium 

DB_RPT09 


Frequency: 

weekly. 

Criteria: 

POLICY_ 

STATUS equals 

"PPAY" 


DB 

POLICY; 

POLICY 

STATUST 

POLICY 

PREMIUM 

BILLING 


This report identifies policies lapsed for non- 
payment of premium. Detailed information 
presented in this report includes: DB policy 
information (POLICY NUMBER; 
PAIDTOJDATE; DEBIT MODE). Input 
parameters include: REPORT ID; 
REPORT NAME; SYSTEM MAXIMUM 
DATE; INC DATE. 


Policies Not 
Premium 


Frequency: 
weekly. 


DB 

POLICY; 


This report identifies policies in which the 
premium has not been paid for 3 1 days. 
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Name 


Frequency and 
Criteria 


Tables 
Accessed 


Description 


Paid for 31 
Days 

DBJRPT05 


Criteria: 
POLICY_ 
STATUS equals 
"PPAY" 


POLICY 
STATUS; 
POLICY 
MODAL 
PREMIUM 


Detailed information presented in this report 

includes: DB policy information (POLICY 

NUMBER; PAID TO DATE; 

DEB I TMODE ; DATE_ LASTPAID); policy 

modal premium information 

(MODAL PREMIUM). Input parameters 

include: REP ID; REP NAME. 


Policies 
Overdue 
For 

Minimum 

Interest 

Payment 

DBRPT39 


Frequency: 

weekly. 

Criteria: 

POLICY 

STATUS in 

"PPAY," 

"WAIV," 

"PDUP," 

"PUE," or equals 

"DTHF"; 

DEBIT_TRANS_ 

TYPE equals 

MININT 


DB 

POLICY; 
POLICY 
STATUS; 
POLICY_ 
LOAN 
TRANS- 
ACTION 


This report presents information regarding 
policies overdue on account of overdue 
minimum interest payment. Detailed 
information presented in this report includes: 
DB policy information (DEBIT JVIODE); 
Policy Loan Transaction information 
(POLICY NUMBER; 
INTEREST DUE DATE; 
MINIMUM INTEREST); policy status 
information (POLICY_STATUS; 
START DATE). Input parameters include: 
PREPJD; P REP NAME. 


Policies On 
Waiver Due 
To Mature 

DB_RPT37 


Frequency: 

monthly. 

Criteria: 

POLICY 

STATUS equals 

"WAIV" 


DB 

POLICY 
POLICY 
STATUS 


This report provides information regarding 

policies on waiver due to mature. Detailed 

information presented in this report includes: 

DB policy information (POLICY NUMBER; 

MATURITYD ATE ; DEBITMODE) policy 

loan transaction information 

(POLICY NUMBER; INTEREST DUE 

DATE; MINIMUM INTEREST); policy status 

information (POLICY_STATUS; 

START DATE). Input parameters include: 

P REP ID; P REP NAME. 


Policy 

Modal 

Premium 

Decrease 

Notification 

DB_RPT14 


Frequency: 
not defined. 
Criteria: 
STOP_DATE = 
predefined date, 
e.g., "12th Dec 
2099" 


POLICY 
PREMIUM^ 
BILLING; 
DB 

POLICY; 

POLICY 

STATUS; 

DEBIT 

CLIENT 


This report provides notification of a decrease 

in policy modal premium. Detailed information 

presented in this report includes: 

BILLING ACCOUNTNUMBER; 

DEBIT MODE; POLICY_STATUS; 

NAME LAST. Input parameters include: 

POLICY NUMBER; PREVIOUS^ 

PREMIUM VALUE; 

CURRENTJPREMIUM_VALUE; 

PREMIUM START DATE; 

COVERAGE SEQUENCE; START DATE. 


Premium 
Payments 
Report 

(DB_RPT10 


Frequency: 
daily. 
Criteria: 
none. 


W 

BATCH 
PAYMENT 


This report identifies premium payments. 
Detailed information presented in this report 
includes: W_BATCHPAYMENT information 
(BILLING ACCOUNT NUMBER; 
CHECK DIGIT; DATE PROCESSED; 
BATCH NUMBER; SEQUENCE 
NUMBER 5; COMPANY CODE_2; 
PREMIUMJDUE; 
PREVIOUS AMOUNT PAID; 
CURRENT_AMOUNT_P AID) . Input 
parameters include: REP ID; REP NAME. 
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Name 


Frequency and 
Criteria 


Tables 
Accessed 


Description 


Rider 

Expiry Date 
Or "YOC" 
Coming 
Due Date 

DB_RPT01 


Frequency: 
monthly. 
Criteria: 
COVERAGE 
SEQUENCE 
greater than 1 ; 
Order by DEBIT 
MODE in 
descending order 


DB 

POLICY; 
POLICY 
COVER- 
AGE 


This report presents information pertaining to 
rider expiry date or YOC (year of change) 
coming due date. Detailed information 
presented in this report includes: DB policy 
information (POLICY_NUMBER; 
DEBIT MODE; policy coverage information 
(COVERAGE_ SEQUENCE; PLAN CODE; 
STOP DATE). Input parameters include: 
PRESENTED ATE. 


WP 

Reminder 
Notice 

DB_RPT33 


Frequency: 

daily. 

Criteria: 

PAYORTYPE = 
"P"; 

DEBIT MODE = 
"WP"; 
POLICY 
STATUS 
="PPAY"; 
PARAMETER_ 
APPLIED FLAG 
= "Y"; 

number of modal 
premiums paid >= 
13; 

DEBIT TRANS_ 
TYPE = 
"PAYPRM" 


DB 

POLICY; 
POLICY 
STATUS; 
POLICY 
MODAL 
PREMIUM; 
POLICY 
PREMIUM 
BILLING; 
BILLING 
ACCOUNT 
JTRANS; 
BILLING 
ACCOUNT 
PAYOR; 
BILLING 
ACCOUNT. 


This report provide weekly premium (WP) 
reminder notices. Detailed information 
presented in this report includes: 
DB policy information (INSURED CIN; 
POLICY TYPE; DEBIT MODE); POLICY 
STATUS Information (POLICY_STATUS); 
policy modal premium information 
(MODAL PREMIUM); policy premium billing 
information (POLICY_ NUMBER); billing 
account transaction information 
(BILLING_ACCOUNT_NUMBER; PAID_ 
UP DATE; 

PREMIUM_P A YMENTAMOUNT ; 
PAYMENT_APPLIED_FLAG); billing 
account payor information (PAYOR ID 
NUMBER; PAYOR TYPE); billing account 
information (CHECK DIGIT). Input 
parameters include: REP ID; REP_NAME. 



Table IV: Exemplary Screen Descriptions 



Screen Name 


Tables Accessed 


Description 


Policy Data Screen 

(DB POLCY) 
(FIG. 11) 


DB POLICY, 
DEBITCLIENT 


The Policy Data Screen pulls up policy details in 
response to input of a policy number. The 
"UPDATE INSURED NAME" and "UPDATE 
BENEFICIARY NAME" buttons on the screen allow 
the user to modify the beneficiary and insured names, 
respectively. The "RESTORE LOST POLICY" 
button allows the user to add policies in case the 
policy details are not found. 


Policy Coverage 

(DB POLCV) 
(FIG. 12) 


POLICY^ 
COVERAGE 


The Policy Coverage Screen allows the user to add or 
modify coverage record details for a policy in 
response to input of a policy number. The "Coverage 
Sequence" listed on the screen is generated by the 
insurance processing system 102 for each coverage 
record. 


Policy Status Screen 

(DB POLST) 
(FIG. 13) 


POLICY 
STATUS 


The Policy Status Screen retrieves the status of a 
policy for various date ranges. Further, the user can 
query on an existing policy number to retrieve status 
information pertaining to the policy. Further, the 
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Screen Name 


Tables Accessed 


Description 






"GENERATE REFUND" button allows the user to 
generate a premium refund for policies that have 
become paid up. The "REVERSE REFUND" button 
allows the user to reverse the refund operation. 


Policy Summary 

(DB POLSU) 
(FIG. 14) 


DBjPOLICY 


The Policy Summary Screen provides summary 
details for a policy in response to the input of a valid 
policy number. In one embodiment, this screen does 
not permit users to modify the data presented on the 
screen. 


Non Converted 
Policies 

DB POLNC 
(FIG. 15) 


POLICIES NOT 
CONVERTED 


The Policies Not Converted Screen presents 
information pertaining to policies that are not 
converted into the Debit system. In one embodiment, 
the polices are stored in a representation 1 15 of an 
"old" mainframe system (such as the "previous 
system" 1 14 shown in FIG. 1). 


Policy Maturity Year 
Screen 

(DB MATUR) 
(FIG. 16) 


DB_POLICY 


The Policy Maturity Year Screen allows a user to 
make corrections to maturity dates for policies. 
More specifically, this screen lists policies having 
blank (i.e., unspecified) maturity dates because the 
data was lost on the previous system 1 14. Users may 
query on "Maturity Year ," "Policy Begin," or 
"Policy End." A user may view the maturity dates 
corrected by a particular user by querying on the user 
ID and placing a check in the "Corrected Maturity 
Dates" checkbox. 


Billing Account 
Information Screen 

DB BLACT 
(FIGS. 17 and 18) 


BILLING 

ACCOUNT, 

POLICY 

PREMIUM 

BILLING 


The Premium Billing Account Screen presents billing 
account details in response to input of Account 
number, Account status, Paid to Date, Discount 
Code, or Policy Type (e.g., WP, MDO). This screen 
enables the user to add policies or remove policies 
for a billing account. Further, this screen enables a 
user to add a new billing account. 


Billing Account 
Policy Association 

DB PREBG 
(FIG. 19 ) 


POLICY 

PREMIUM 

BILLING 


The Billing Account Policy Association Screen 
shows the association between a billing account and 
its policies. The screen enables users to query on 
either policy number, billing account number, or 
both. Further, this screen allows users to add policies 
or remove policies associated with a particular billing 
account. 


Billing Account 
Transaction 

(DB BLTRN) 
(FIG. 20) 


BILLING ACCO 
UNT_TRANS 


The Billing Account Transaction Screen permits the 
user to fetch billing account transaction details, as 
well as enter new payment transactions, by entering a 
valid billing account number. When the user enters 
the "Amount Received" and invokes the "APPLY 
PAYMENT" button, the system calculates the 
number of modal premiums corresponding to the 
"Amount Received" and "Premium Payment" 
variables. The system adds a balance amount (if any 
exists) to the partial payment field. When the partial 
payment reaches one modal premium, the system 
creates a record in the 
BILLING_ACCOUNT_TRANS table with 
transaction type SYSPRM. 


Policy Modal 


POLICY 


The Policy Modal Premium Information Screen 
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Screen Name 


Tables Accessed 


Description 


Premium 
Information 

(DB MODPR) 
(FIG. 21) 


MODAL 
PREMIUM 


retrieves modal premiums for policies in a specified 
date range. The screen allows a user to query on an 
existing policy number and then add a new modal 
premium, as well as its start date. 


Premium Refund 
Information 

(DBPRREF) 
(FIG. 22) 


PREMIUMJREF 
UND 


The Premium Refund Information Screen allows a 
user to view and make premium refunds. In 
operation, the screen enables a user to query on a 
policy number and then generate a refund or reverse 
a refund by pressing the "GENERATE REFUND" 
and "REVERSE REFUND" buttons, respectively. 
Further, the screen gives the user the option to apply 
the balance paid up amount to other policies or to 
refund it. If any premium payment exists, then the 
system will call the Billing Account Transaction 
Screen and generate a record there. 


Premium Waiver 
Screen 

(DB PRWAI) 
(FIG. 23) 


PREMIUM_ 
WAIVER 


The Premium Refund Information Screen retrieves 
policies along with the date ranges for which the 
policies are in waiver state. The user can instruct the 
system to generate a refund for premiums paid during 
the waiver period by invoking the "Generate Refund" 
button. In response, the system generates a Refund 
Sequence No. for that policy. A user may instruct 
the system to perform a reverse refund transaction (if 
needed) by invoking the "Reverse Refund" button. 
Further, a user can terminate the waiver status for a 
policy by invoking the "Terminate Waiver" button. 
A user may also terminate a waiver by pressing 
"Reverse Termination" button. 


Loan Maintenance 
Screen 

(DB LOANP) 
(FIG~S.24and25) 


POLICY LOAN , 
DEBIT_CLIENT; 
POLICY LOAN 
TRANSACTION 


The Loan Maintenance Screen retrieves the loan 
transactions for a policy in response to entry of a 
valid policy number. A user may view the loan 
details (such date due, minint, etc.) by pressing the 
arrow button (in lower right of screen). Further, the 
screen allows a user to add a new loan for the 
displayed policy. Further still, this screen enables a 
user to modify the "Payor Name" and "Address." In 
this particular exemplary application, a user may also 
modify the subscriber's Florida Name and Address. 


Loan Quote and 
Approval Quote 

(DB LNQOT) 
(FIG. 26) 
(DBLNAPP) 
(FIG. 27) 


LOAN 
APPROVAL 


The Loan Approval and Loan Quote Screens allow 
the user to process new loans. More specifically, the 
screens enable a user to query on an existing policy 
number to view the loan details. In order to process 
a new loan, the screen prompts the user to enter a 
policy number, loan date, and loan amount. In one 
embodiment, the loan amount should be less than the 
cash surrender value for the policy. When the user 
presses the "Loan Approval" button, the system 
approves or denies the loan (e.g., depending on the 
CSV value). The screen indicates whether the 
system has approved or denied the loan by posting a 
"Y" or "N" symbol in the "Approval Indicator" field. 


Policy Loan Master 

(DB PLOAN) 
(FIG. 28) 


POLICY_LOAN 


The Policy Loan Screen retrieves loan details for the 
policies. This screen allows the user to modify the 
interest rates applicable to the loans. 
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Screen Name 


Tables Accessed 


Description 


Cash Surrender 
Quote 

(DB CSVQU) 
(FIG. 29) 


DB_POLICY 


The Cash Surrender Quote Screen allows the user to 
query on a valid policy number to retrieve the Cash 
Surrender Value (CSV) details for the corresponding 
policy. In one embodiment, the screen does not 
permit users to modify any of the fields on the 
screen. 


Cash Surrender 
Value 

(DB CSVRV) 
(FIG. 30) 


POLICY CSV 
TRANSACTION 


The Cash Surrender Value Screen allows users to 
generate and reverse cash surrender value 
transactions for an identified policy. The screen 
permits the user to query on an existing policy 
number. By invoking the "Cash Surrender" button, 
the system calculates the CSV amount for the 
identified policy. More specifically, to calculate the 
CSV amount for the policy, the system fetches the 
ISSUE AGE, PLAN CODE, RATE BOOK, and 
UNITS values from the POLICY COVERAGE 
table. The system uses these values, in conjunction 
with the CSV RATE table, to compute the CSV 
amount. The user may reverse the surrendered policy 
by activating the "Reverse" button. 


CSV Rate 

(DB CSVRT) 
(FIG. 31) 


CSVRATE 


The CSV Rate Screen retrieves and displays the Cash 
Surrender Value factor table. The system calculates 
the CSV amount for a policy using this CSV factor 
table. In one embodiment, the screen does not permit 
the user to add or modify the rate books. 


Plan Codes 

(DB PLCOD) 
(FIG. 32) 


PLANCODES 


The Plan Code Screen retrieves the plan codes and 
the corresponding plan descriptions from the data 
storage 206. The screen allows a user to add or 
modify plan codes. 


Policy CSV 
Transaction 

DB CSVTR 
(FIG. 33) 


POLICY CSV 
TRANSACTION 


The Policy CSV Transaction Screen retrieves the 
CSV transaction records for a policy. The screen 
permits a user to add a new CSV transaction, or to 
modify an existing CSV transaction. 


Extended Values 
Main Screen 

(DB EXTVA) 
(FIG. 34) 


DB_POLICY 


The Extended Values Main Screen allows a user to 
modify the policy type to an Extended Term 
Insurance (ETI) type or a Reduced Paid Up (RPU) 
type. In operation, the user calls up a policy by 
entering a valid policy number. The system 
calculates the CSV amount and the number of years 
of extended term or the reduced paid up coverage 
available from that amount. The system then adds 
this information to the CSVJTRANSACTION table 
and changes the status of the policy to ETI or RPU 
depending on whether the Extended Term Insurance 
or Reduced Paid Up options are selected, 
respectively. 


Extended Term 
Insurance 

(DB REVEX) 
(FIG. 35) 


T>r\j Tr^v r*Q\? 
TRANSACTION 


The Extended Term Insurance Screen retrieves the 
details of an Extended Term Insurance-type policy 
when the user inputs a valid policy number of the 
LPNVL or ETI type. The screen permits the user to 
restore the status to its prior state by activating the 
"Reverse" burton, but only if the policy was 
premium-paying or in waiver state. 


Reduced Paid Up 


POLICY CSV 


The Reduced Paid Up Screen retrieves details of a 
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Screen Name 


Tables Accessed 


Description 


Screen 

(DB REVRP) 
(FIG. 36) 


TRANSACTION 


RPU-type policy in response to the user inputting a 
valid policy number of the RPU-type. In one 
embodiment, the screen permits the previous status 
of the policy to be restored by pressing the "Reverse" 
button, but only if the policy was premium-paying or 
in waiver state. 


Extended Rate 

(DB EXTRT) 
(FIG. 37) 


EXT_RATE 


The Extended Rate Screen retrieves the extended rate 
factor table used during conversion of a policy to 
ETI-type. In one embodiment, the screen does not 
permit the user to add or modify the rate book. 


Access Role Entry 
Screen 

(DB ACROL) 
(FIG. 38) 


DB ACCESS 
ROLE 


The Access Role Entry Screen permits an 
administrator to control access to the interface 
screens. More specifically, this screen pulls up a list 
of roles and privileges currently applicable for the 
screens. The screen permits the user to add, modify 
or delete access roles and privileges for the screens. 


Error Message 

(DB ERDEF) 
(FIG. 39) 


DBJERROR_ 
MESSAGEJDEF 


The Error Message Entry Screen retrieves and 
displays error messages (along with associated error 
types and error numbers) generated by the debit 
system's screens. 


Report Definition 
Screen 

(DB RPTDF) 
(FIG. 40) 


DB REPORT^ 
DEF 


The Report Definition Screen retrieves and displays 
valid report IDs and associated report names and run 
modes (specifying whether report is online or batch). 
The screen permits a user to add, modify or delete a 
report. 


Form Definition 
Screen 

(DB SCREN) 

(Fia4i) 


DB SCREEN_ 
DEF 


The Form Definition Screen retrieves all of the valid 
screen IDs and screen names in the debit system from 
the data storage 206. The screen permits a user to 
add modifv or delete ID and name information. 


Actuarial Extracts 
Request Screen 

(DB ACEXF) 
(FIG. 42) 


None 


The Actuarial Extracts Screen allows a user to 
generate an actuarial extract file for use by actuarial 
personnel within an organization. In operation, the 
user enters the date and location of the extract file. 
The user then creates the actuarial extracts file by 
pressing the "Generate Extracts" button. 


Error Log 

(DB ERROR) 
(FIG. 43) 


DBERRORS 


The Error Log Screen retrieves the details of the 
errors generated during execution of the batch 
programs (which are trapped in the DB ERRORS 
table). The screens allows a user to query on the 
batch "Program name," "Run by," or "Run date" 
fields to retrieve the error messages. 



Table V: On-Line Reports 



Name 


Frequency 
& Criteria 


Tables 


Description 


Changes to 
Policies on 
Waiver 

DB RPT36 


Frequency: 
daily. 
Criteria: 
not defined. 


POLICY 
STATUS 


This report presents information on changes to 
policies on waiver. Detailed information in this 
report includes: POLICY NUMBER; 
START DATE; STOP DATE. Input 
parameters include: FROM DATE; 



56 



Attorney Docket No. 52493.000121 



Name 


Frequency 
& Criteria 


Tables 


Description 








TO DATE. 


Checklist of 

Policies 

Cash 

Surrendered 

DB_RPT07 


Frequency: 
daily. 
Criteria: 
not defined. 


DB 

POLICY; 
POLICY 
CSV_ 
TRANS- 
ACTION; 
POLICY ST 
ATUS 


This report provide a checklist concerning 
policies that have been cash surrendered. 
Detailed information in this report includes: 
policy cash surrender value transaction 
information (POLICY NUMBER; 
CSV EFFECTIVE DATE; 
INTEREST REFUND / DEDUCT; 
PREMIUM REFUND / DEDUCT; 
SURRENDER AMOUNT; LOAN_ 
BALANCE_AMOUNT); DEBIT MODE; 
POLICY START DATE. Input parameters 
include: START DATE; STOP DATE. 


Debit PINQ 
Report 

DBPINQ 


Frequency: 
daily 
Criteria: 
not defined 


DB 

POLICY; 
DEBIT 
CLIENT; 
POLICY 
COVER- 
AGE; 
POLICY_ 
LOAN; 
POLICY 
MODAL_ 
PRIMIUM; 
POLICY_ 
STATUS 


The Debit PINQ Report includes the following 
information: debit policy information (POLICY 
NUMBER; POLICY ISSUE_DATE; 
POLICY PAID UP DATE; 
POLICY EXPIRY DATE; 
DATE LAST PAID; PAID TO DATE; 
POLICY MATURITY DATE; MATURITY_ 
REPORTED; POLICY_TYPE; 
DEBIT MODE; INDUSTRIAL FLAG; 
YEAR OF CHANGE DATE; INSURED_ 
CIN; VALUATION_CLASS; 
BENEFICIARY^ CIN; 
APPLICANT AGE RANGE; 
MATURITYEXPIRY YEAR; 
CONVERSION STATUS); policy status 
information (POLICY_STATUS; 
POLICY_START_DATE); debit client 
information (LAST NAME; 
TAX IDENTIFICATION NUMBER; 
ADDRESS STATE_CODE; 
MODAL PREMIUM); policy coverage 
information (PLAN CODE; 
SEX RELATIONSHIP; 
AMOUNT OF INSURANCE; 
ULTIMATE_FACE_AMOUNT; 
ISSUE AGE); policy loan information 
(INTEREST RATE; 

INTEREST NEXT DUE DATE). Input 
parameters include: MATURITY YEAR 


Extended 

Value 

Report 

DB_RPT35 


Frequency: 
daily. 
Criteria: 
not defined. 


POLICY 
CSV 
TRANS- 
ACTION; 
POLICY_ 
STATUS 


This report provides information pertaining to 
extended value-related matters. Detailed 
information presented in this report includes: 
policy CSV transaction information 
(POLICY NUMBER; 
CSV EFFECTIVE DATE; CSV_ 
TRANSACTIONJTYPE; 
SURRENDER AMOUNT; 
EXTENTION TERM YEAR; 
EXTENTION TERM DAYS; 
REDUCED PAID UP AMOUNT); 
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Name 


Frequency 
& Criteria 


Tables 


Description 








POLICY STATUS. Input parameters include: 
FROM DATE; TO DATE. 


Invalid 
Billing 
Accounts 

DB_RPT17 


Frequency: 
daily. 
Criteria: 
not defined. 


BILLING 
ACCOUNT 


This report provides information pertaining to 

invalid billing accounts. Information presented 

in this report includes: 

BILLING ACCOUNT NUMBER; 

DEBIT MODE; PAID TOJDATE; 

P ARTI ALP A YMENT_B AL ANCE . Input 

parameters include: none 


Lapses And 
Revivals 
With Loans 

DBRPT18 


Frequency: 
daily. 
Criteria: 
not defined. 


POLICY_ 
STATUS; 
POLICY 
LOAN 
TRANS- 
ACTION; 
DB_POLICY 


This report provides information concerning 
lapses and revivals associated with loans. 
Detailed information presented in this report 
includes: policy status information 
(POLICY STATUS; 
POLICY START DATE; 
POLICY STOP DATE); DB policy 
information (POLICY_UMBER; 
DEBIT MODE); policy loan transaction 
information (TRANSACTION EFFECTIVE_ 
DATE; TRANSACTION AMOUNT). Input 
parameters include: 
EFFECTIVE FROMJDATE; 
EFFECTIVE TO DATE. 


Loan 
ADDINT 
Transactions 
Listings 

DB_RPT48 


Frequency: 

Criteria: 
not defined. 


POLICY_ 
LOAN 
TRANS 
ACTION. 


This report presents loan ADDINT transactions 
listings. Detailed information presented in this 
report includes: policy loan transaction 
information (POLICY_NUMBER; 
DEBIT TRANSACTION TYPE; 
TRANSACTION_EFFECTIVE_DATE); 
TRANSACTION_ AMOUNT. Input 
parameters include: EFFECTIVE 
FROM DATE: EFFECTIVE TO DATE. 


Loan 

Activity 

Report 

DB RPT21 


Frequency: 
daily: 
Criteria: 
not define. 


POLICY_ 
LOAN 
TRANS- 
ACTION; 


This report presents loan activity report 
information. Detailed information presented in 
the report includes: policy loan transaction 
information (POLICY_NUMBER; 
DEBIT TRANSACTION TYPE; 
TRANSACTION_EFFECTIVE_DATE; 
DATE OF RECEIVE; 
TRANSACTION_AMOUNT). 
Input parameters include: 
EFFECTIVE FROM DATE; 
EFFECTIVE TO DATE; FROM POLICY; 
TO POLICY. 


WP Policies 
Loan 
Payment 
Statement 

DB_RPT49 


Frequency: 
on request. 
Criteria: 
not defined. 


POLICY 
LOAN 
TRANS- 
ACTION 


This report presents a WP policies loan 
payment statement. Detailed information 
presented in this report includes: 
BEGINNING BALANCE; 
BEGINNING COUNT; NEWJLOANS; 
REINSTATED; INTEREST; 
ADJUSTMENTS; LAPSES; 
CURRENT_WEEK_ BALANCE; 
ENDING COUNT. Input parameters include: 
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Name 


Frequency 
& Criteria 


Tables 


Description 








START DATE; END DATE. 


Loan 


Frequency: 


DB 


This reports presents loan payment information. 


Payment 


on request. 


POLICY; 


Detailed information presented in this report 


Report 


Criteria: 


POLICY LO 


includes: POLICY NUMBER; 


DB RPT11 


DEBIT 
TRANS 


AN 

TRANS- 


DATE EFFECTED; DATE RECEIVED; 
TRANSACTION TYPE; 




TYPE in 


ACTION 


TRANSACTIONAMOUNT. Input 




"PAYINT," 




parameters include: START DATE; 




"PAYPRIN," 




END_DATE 




"UNERNINT," 








"REFPRIN," 








"ADDINT," 








"NEWINT," 








"MININT"; 








DEBIT_ 








MODE in 








"MDO," "WP" 






Loan Payoff 


Frequency: 


POLICY_ 


This reports presents a loan payoff list. 




weekly. 


LOAN; 


Detailed information presented in this report 




Criteria: 


POLICY_ 


includes: POLICY NUMBER; 


DBRPT22 


Debit Trans 


LOAN 


PAY OFF DATE; 






TRANS- 


PRINCIPAL PAYMENT AMOUNT; 




"PAYPRIN" 


ACTION 


UNEARNED INTEREST; 
BALANCE_AMOUNTBEFORE_PAYMEN 
T. Input parameters include: FROM DATE; 
TO DATE; 


MDOAVP 
Excess Loan 


Frequency 

on request. 


POLICY 
LOAN; 


This reports presents information concerning 
MDOAVP excess loan matters. Detailed 


Criteria: 


DB 


information presented in this report includes: 


Report 


COVERAGE 


OLICY; 


POLICY NUMBER; RATE; PLANCODE; 


JJr5 KrDo 


SEQUENCE = 


POLICY 


ISSUE AGE; ISSUE DATE; 




1; 


COVER- 


INSURANCE AMOUNT; CSV AMOUNT; 




POLICY_ 


AGE; 


LOAN AMOUNT; EXCESS_AMOUNT; 




STATUS in 


POLICY 


INT RATE; INT_ YR; MAT YR. Input 




"PPAY," 


STATUS; 


parameters include: AS_OF_ DATE. 




"WAIV," 








"PDUP" 






Minimum 


Frequency: 


POLICY 


This report includes the following detailed 


Interest Due 


on request. 


STATUS; 


information: POLICY TYPE; 


Report 


Criteria: 


DB 


POLICY NUMBER; 


DBRPT19 


POLICY_ 


POLICY; 


INTEREST DUE DATE; 


STATUS in 


POLICY_ 


MINIMUMJNTEREST_AMOUNT. Input 




"PPAY," 


LOAN_ 


parameters include: none 




"WAIV," 


TRANS- 






"PDUP," 


ACTION 






"PUE," 








"DTHF"; 








INTEREST D 








UE DATE < 








SYS DATE; 








DEBIT TRAN 








S TYPE = 








"MININT" 
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Name 


Frequency 
& Criteria 


Tables 


Description 


New and 
Additional 
Loans 
Reports 

(DB_RPT20 


Frequency: 
on request. 
Criteria: 
DEBIT 
TRANS- 
ACTION 
TYPE 
="NEW- 
LOAN" 


DB 

POLICY; 
POLICY 
LOAN; 
POLICY_ 
LOAN 
TRANS- 
ACTION 


This report provides information regarding new 
additional loans. Detailed information 
presented in this report includes: 
POLICY NUMBER; 
ANNIVERSARY DATE; 
PREVIOUS LOAN BALANCE; 
NEW LOAN BALANCE; 
INTERESTRATE. 

Input parameters include: START_DATE; 
END DATE. 


Paid up 

Policy 

Notification 

DBRPT15 


Frequency: 
on request. 
Criteria: 
STOPDATE 
= predefined 
date, e.g., 
12-Dec-2099; 
START_ 
DATE, PAID_ 
UP DATE < = 
SYSDATE; 
PDUP LET- 
TER SENT = 
"N" 


DEBIT 

CLIENT; 

POLICY 

MODEL_ 

PREMIUM; 

DB 

POLICY; 
POLICY_ 
STATUS; 
POLICY_ 
COVER- 
AGE; 
POLICY 
PREMIUM_ 
BILLING; 
BILLING 
ACCOUNT 
PAYOR 


This report provides notification of a paid up 
policy. Detailed information presented in this 
report includes: NAME; ADDRESS; 
POLICY NUMBER; ACCOUNT NUMBER; 
NAME OF INSURED; 
AMOUNT OF INSURANCE; ISSUE_AGE; 
POLICYJDATE; P AID UP D ATE ; 
PREMIUM; OUT- 

STANDING_LOAN_AMOUNT_AS_OF_ 
DATE. Input parameters include: none 


Paid Up 
Refund 
Report 

DBRPT06 


Frequency: 
on request. 
Criteria: 
REFUND 
TYPE = "PUP" 


DB 

POLICY; 

PREMIUM 

REFUND 


This report provides information regarding paid 
up refunds. Detailed information presented in 
this report includes: POLICY NUMBER; 
PAID_UP_DATE; REFUND_AMOUNT; 
Total. Input parameters include: 
START DATE: STOP DATE. 


Payments 
From 
Bank(s) - 
Received & 
Applied 
DBRPT60 


Frequency: 
on request. 
Criteria: 


W BATCH 

PAYMENT; 

BILLING 

ACCOUNT 

TRANS 


This report presents information regarding 
payments received from the banks, and 
subsequently applied. Detailed information 
presented in this report includes: 
ACCOUNT NO; PREMIUM_DUE; 
AMOUNT MODAL PREMIUMS; 
TRANSACTION TYPE; PAIDTO^ DATE; 
PREMIUM_PAYMENT; 
PARTIALPAYMENT; 
PAYMENT_STATUS. Input parameters 
include: none 


Policies 
Going On 
Waiver 
During a 
Requested 
Time Period 

DB_RPT40 


Frequency: 
on request. 
Criteria: 
WAIVER_ 
START 
DATE = 
Max(WAIVER 
STATE 


PREMIUM^ 
WAIVER 


This report displays the policies going on 
waiver during a specified input date range for 
WP and MDO debit modes. Detailed 
information presented in this report includes: 
POLICY NUMBER; 
WAIVER START DATE; 
PREMIUM REFUND_AMOUNT; TOTAL_ 
REFUND AMOUNT (for WP and MDO); 
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Name 


Frequency 
& Criteria 


Tables 


Description 




DATE) for 
each Policy 




GRAND_TOTAL_OF_ REFUND (WP + 
MDO). Input parameters include: 
FROM DATE; TO DATE. 


Policy Data 
Form 

DB_RPT38 


Frequency: 

unspecified; 

Criteria: 

CSV TRANS_ 

TYPE = "s"; 

COVERAGE_ 

SEQUENCE 

= l; 

REVERSAL 
ENTRY_ 
DATE is null 


DB 

POLICY; 
POLICY 
LOAN; 
POLICY 
CSV 
TRANS- 
ACTION; 
POLICY 
COVER- 
AGE; 


This Report displays CSV details for a selected 
input policy. Detailed information presented in 
this report includes: POLICY NUMBER; 
NAME OF INSURED; EFFECTIVE_DATE; 
AGE AT ISSUE; DATE_OF_ISSUE; 
TYPE OF INSURANCE; DURATION; 
POLICY AMOUNT; YEAR_OF_CHANGE; 
INTEREST PAID TO YEAR; 
OUTSTANDING LOAN; INTEREST_RATE; 
INTERESTJDEDUCTION; GROSSJVALUE; 
NET VALUE. Input parameters include: 
POI.TCY NUMBER. 


Policy 
Number 
Order List 

DB_RPT62 


Frequency: 

on request. 

Criteria: 

POLICY 

STATUS IN 

("PDUP," 

"PPAY," 

"WAIV"); 

COVERAGE_ 
SEQUENCE = 
1 


DB 

POLICY; 
POLICY 
LOAN; 
POLICY_ 
STATUS; 
POLICY 
COVER- 
AGE; 
POLICY 
LOAN 
TRANS- 
ACTION 


Detailed information presented in this report 
includes: POLICY NUMBER; ISSUE_DATE; 
STATUS; PLAN; AGE; AMOUNT; RATE; 
YEAR; LOAN; NAME OF THE INSURED; 
TOTAL_ FOR_THE_LOAN (WP AND MDO 
DEBIT TYPES). Input parameters include: 
none 


Policy Status 

Change 

Report 

DBRPT04 


Frequency: 
not defined. 
Criteria: 
none 


DB 

POLICY; 
POLICY_ 
MODAL 
PREMIUM; 
POLICY_ 
STATUS; 
POLICY 
COVER- 
AGE; 
POLICY 
LOAN_ 
TRANS- 
ACTION 


This report displays the policies (along with 
their respective statuses) for a specified input 
date range. Old and new status may also be 
displayed for the policies. This report can also 
display the policies having old and new status, 
as determined by the input parameters. 
Detailed information presented in this report 
includes: POLICY NUMBER; 
OLD STATUS; NEW STATUS; 
START DATE; DATE LAST_PAID; 
CURRENT PREMIUM_AMOUNT; LAST__ 
DATE RECEIVED; 
DEATH_CLAIM_INFO_SEND. Input 
parameters include: FROMJDATE; 
NEW DATE; OLD_STATUS; 
NEW_STATUS. 


Policy Status 

Change 

Report 

(Having 

Loans) 

DBJRPT50 


Frequency: 
on request. 
Criteria: 
not defined. 


DB 

POLICY; 

POLICY_ 

MODAL 

PREMIUM; 

POLICY_ 

STATUS; 

POLICY 


This report displays the policies (having loan 
transactions) along with the status (old and new 
status) for a given input date range. It can also 
display the policies having old and new status, 
as determined by the input parameters. 
Detailed information presented in this report 
includes: POLICY NUMBER; 
OLD_STATUS; NEW__STATUS; 
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Name 


Frequency 
& Criteria 


Tables 


Description 






LOAN_ 
TRANS- 
ACTION 


START DATE; D ATE_L AST P AID ; 
LOAN AMOUNT; 

CURRENT PREMIUM AMOUNT. INPUT 
PARAMETERS INCLUDE: FROM_DATE; 
NEW DATE; OLD_STATUS; 
NEW STATUS. 


Premium 
Entered On 
a Given Day 

DB_RPT03 


Frequency: 

on request: 

Criteria: 

DEBIT 

TRAN_ 

TYPE IN 

"PAYPRM," 

"PARTIAL"; 

PAYMENT_ 

APPLIED FL 

AG is "Y" 


BILLING 

ACCOUNT^ 

TRANS 


This reports provides information regarding 
premiums entered on a given day. Detailed 
information in this report includes: 
ACCOUNT NUMBER; 
TRANSACTION_TYPE; AMOUNT_ 
RECEIVED; PREMIUM PAYMENT; 
PARTIAL_PAYMENT; PAID TO DATE. 
Input parameters include: FROM_ DATE; 
TOJDATE; USER-ENTERED /TOTAL. 


Premium 

Refund 

Report 

DBRPT02 


Frequency: 

on request. 

Criteria: 

CSV TRANS_ 

TYPE="S" 


POLICY_ 
STATUS; 
POLICY^ 
CSV 
TRANS- 
ACTION 


This reports displays the details of the reversal 

or extended cash surrender transactions for WP 

and MDO debit modes. Detailed information 

presented in this report includes: 

POLICY NUMBER; EFF DATE; STATUS; 

PRIOR EFF DATE; PRIOR_STATUS; 

EXTENDEDJTERMJPERIOD; 

CSV AMOUNT. Input parameters include: 

FROM DATE; TO DATE. 


Reversal of 
Cash 

Surrender 

DBRPT42 


Frequency: 
on request. 
CSV TRANS 
TYPE = "S" 


POLICY 
STATUS; 
POLICY 
CSV 
TRANS- 
ACTION 


This report displays the details of the cash 
surrender transactions for WP and MDO debit 
modes. Detailed information presented in this 
report includes: POLICYJNUMBER; 
EFFECTIVE DATE; STATUS; 
PRIOR EFFECTIVE DATE; 
PRIOR STATUS; EXTENDEDJTERM 
PERIOD; CSV AMOUNT. Input parameters 
include: FROM DATE; TO DATE. 


Reversal of 

Extended 

Value 

DB_RPT34 


Frequency: 

on request. 

Criteria: 

CSV TRANS_ 

TYPE IN ("E," 

"R") 


POLICY 

STATUS; 
POLICY 
CSV_ 
TRANS- 
ACTION 


This report displays the details of the reversal 
or extended cash surrender transaction 
operation. 

Detailed information presented in this report 
includes: POLICY NUMBER; EFF_DATE; 
STATUS; PRIOR EFF DATE; 
PRIOR STATUS; EXTENDED_TERM_ 
PERIOD; RPU AMOUNT. Input parameters 
include: FROM DATE; TO DATE. 


Totals By 
IVIonth - 
MDO Loans 

DB_RPT56 


Frequency: 
on request. 
Criteria: 
DEBIT 
MODE = 
MDO; 
POLICY 
STATUS IN 
("PPAY," 


DB 

POLICY; 

POLICY 

LOAN; 

POLICY^ 

LOAN 

TRANS 

ACTION; 

POLICY 


This report displays the interest rate along with 
corresponding loan total for each month. It 
also displays the summary of the loan total for 
all months for each interest rate and the grand 
total. Detailed information presented in this 
report includes: MONTH; INTEREST_RATE; 
LOAN TOTAL; TOTAL_5%; TOTAL_6%; 
GRAND TOTAL. Input parameters include: 
AS OF DATE. 



62 



Attorney Docket No. 52493.000121 



Name 


Frequency 
& Criteria 


Tables 


Description 




"WAIV," 
"PDUP") 


STATUS 




Totals By 
Month - Wp 
Loans 

DCJRPT54 


Frequency: 

on request. 

Criteria: 

DEBIT 

MODE = WP; 

POLICY 

STATUS IN 

("PPAY," 

"WAIV," 

"PDUP") 


DB 

POLICY; 
POLICY_ 
LOAN; 
POLICY 
LOAN 
TRANS- 
ACTION; 
POLICY 
STATUS 


This report displays the interest rate along with 
corresponding loan amount total for each 
month. It also displays the loan total summary 
for each interest rate for all the months and the 
grand total. Detailed information presented in 
this report includes: Month; InterestRate; 
Loan_ Total; Total_5%; Total_6%; 
GrandTotal. Input parameters include: 
As_Of_Date. 


WP/MDO 
Inforce 
Health 
Policies 

DBRPT63 


Frequency: 
on request. 
Critieria: 
POLICY 
TYPE = "H" 
POLICY 
STATUS IN 
(PPAY,WAIV, 


POLICY_ 

STATUS; 

DEBIT 

CLIENT; 

DB_ 

POLICY; 


This reports provides a WP/MDO in-force 
health policies list. Detailed information 
presented in this report includes: INSURED; 
POLICY NUMBER; ISSUE DATE; 
DEBITJVIODE; EXPIRYJDATE. Input 
parameters include: none. 


Weekly Life 
And Health 
Premium 
Report 

DC_RPT51 


Frequency: 
on-request 
Criteria: 
undefined. 


None 


This Report displays the total premiums for the 
life and health policies for the WP and MDO 
type of policies. Detailed information 
presented in this report includes: total premium 
for life and health policies for WP and MDO 
types of policies. Input parameters include: 
FROM DATE; TO DATE. 



Table VI: Glossary 



interface 


In one embodiment, an interface refers to a screen, also known 
as a "Graphical User Interface" (GUI), that allows a user to 
access and manipulate data in storage 


batch payments 


Batch payments refer to payments that are sent by the 
policyholders to a bank accompanied by a billing "stub" that 
identifies the billing account to which the payment should be 
applied. The bank then notifies the insurance company on a 
daily basis that the payments have been received. 


batch processing 


Batch processing refers to computer programs executed by 
operators to carry out large-scale processing against a 
database. Usually such processing runs at night when users 
are not online. 


benefit 


A benefit refers to an amount of money to be made under the 
policy contract when certain events occur, such as when the 
insured dies, etc. 


billing account 


This refers to an account used for billing for premiums for one 
or more insurance policies. The account includes a payor 
name and address, a total modal premium (the sum of modal 



63 



Attorney Docket No. 52493.000121 





premiums of all policies on the account), and a payment next 
due date associated with a billing account. 


cash surrender value 


This value pertains to an amount of money at any given time 
during the life of a policy that the policyowner will receive if 
he or she cancels the coverage provided by the policy and 
surrender the policy to the insurance company. 


conversion 


Conversion refers to the transfer of data from the data storage 
for an old system to the data storage for a new system, with 
any manipulations as may be required, so that the data can 
(from that point forward) be processed by the processing logic 
of the new system. 


coverage (policy coverage) 


Coverage refers to the life that is insured by an insurance 
policy. The "base" coverage of a policy refers to the 
insurance for the "primary" insured on the policy. There may 
be secondary insureds, such as a spouse or children. 


data storage 


A data storage comprises any media for electronically storing 
data on a computer system. Such computer system may 
include a server PC, a LAN-based system, tape or disk, 
mainframe storage mechanism, etc. The data may be 
structured as a relational database or may adopt some other 
structure. 


death claim 


A death claim refers to a request for payment under the terms 
of an insurance policy upon death of the insured 


expire 


A policy expires when it terminates without value. A term 
policy usually expires (terminates without remaining value) 
when the term of insurance ends. 


extended term insurance 


This refers to a non-forfeiture option in which the net cash 
value of a policy is applied as a single net premium to 
purchase term insurance. 


extended values processing 


Extended values processing refers to a logical processing 
performed (computation of cash surrender value, etc.) in order 
to lapse a policy to extended term status. 


external system 


An extended system is a system that exists independently of 
another system, but the two systems can communicate 
(exchange data) with each other and perform needed 
processing on behalf of each other. 


holding transaction 


A holding transaction is a transaction that records a payment 
against a particular policy or account but does not "apply" the 
payment because the payment amount does not match a billed 
amount and therefore it is not yet known how the payor 
intended the payment to be applied. 


interest (loan) 


In one case, interest refers to the annual interest charged to a 
policy loan. 


lapse 


Lapse refers to any termination from an "inforce' status to a 
non-inforce status or from a premium-paying status to a non- 
premium paying status. For instance, policies which go from 
premium-paying status to extended term, or any policies that 
go to surrendered, or death-claim paid status are said to have 
"lapsed." 


loan processing 


Loan processing refers to logical processing performed in 
order to: set up a loan on a policy, charge annual interest, bill 
for annual interest, record payments against principal or 
interest, etc. 


matching payment 


A payment where the dollar amount of the payment matches: 
(1) a multiple of a billing account's modal premium in the 
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case of a premium payment; or (2) the amount of annual 
interest billed in the case of a loan payment. 


mature 


A policy is said to mature when it reaches the date on which 
the cash value of the policy equals the face amount of 
insurance paid by the policy. 


matured endowment 


This refers to an insurance policy where the cash value has 
become equal to the face amount of the insurance paid by the 
policy (and the insured is still living). 


maturity claim 


A maturity claim is a request for payment under the terms of 
an insurance policy upon the policy having reached maturity. 


minimum interest 


This refers to a minimum amount that the policyholder must 
pay to keep a policy with a loan in force, because otherwise 
the cash value of the policy will be less than the outstanding 
loan amount on the policy. 


mirror [of a retired system] 


A "mirror" pertains to a storage of data on a new system that 
records the value of all data fields on all policies as they 
existed when an old system was converted to the new system. 


modal premium 


A modal premium pertains to a minimum premium amount 
which must be contractually paid on a periodic basis (e.g., 
either weeklv or monthly) to keep the policy in force. 


non- forfeiture rights 


A policyholder has rights to use the built-up or remaining cash 
value of a policy in order to continue to have insurance 
coverage for some length of time after the policyholder elects 
to discontinue paving premiums. 


non-matching payment 


A non-matching payment is a payment where the dollar 
amount of the payment does not match: (1) a multiple of a 
billing account's modal premium in the case of a premium 
payment; or (2) the amount of annual interest billed in the case 
of a loan payment. 


maturity date 


The maturity date is the calendar date as of which the cash 
value of an endowment policy will be equal to the policy's 
face value Cinsurance value). 


paid to date 


This is the date up to which a policy will remain in force 
based on the premiums paid to date. 


paid up date 


This is the calendar date as of which all premium payments 
contractually agreed to under the terms of a policy will have 
been made. 


policy maintenance 


Policy maintenance refers to processing involved in the 
administration of a policy, such as maintaining insured name 
and date of birth, tracking cease dates of coverage and 
benefits, recording policy status as of any given date, etc. 


premium billing and payment 
processing 


This refers to printing and mailing billing statements, and then 
applying payments that are received (crediting them to 
particular policies). 


premium-paying status 


A premium-paying status refers to a status indicating that a 
policy is in force and requires additional premium payments to 
remain in force (the policy is not yet paid up). 


premium refund 


A premium refund refers to a refund of premium payments to 
the policyholder because for some reason excess payments 
have been received. 


principal (loan) 


The principal on a loan is the amount of a loan on a policy 
before interest has been added. 


reduced paid up insurance 


This term refers to a non-forfeiture option wherein the cash 
surrender value is used to buy an amount of paid up insurance 
that will mature on the same date as the maturity date of the 
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original policy. 


retired system 


A retired system refers to a computer-based processing system 
that is no longer used. In the context used herein, it is the 
"ancestor" system of the current (new) system. A conversion 
is carried out in order to transfer data from the retired system 
to the new system. 


rider 


A rider is an additional or "secondary" coverage under an 
insurance policy. 


surrender 


To surrender a policy means to stop premium payments on a 
policy and receive a payment of the cash value of the policy. 


unearned interest 


When a payment is made against loan principal, this is the 
amount of the annual interest that must be refunded to the 
policyholder because interest is charged in advance. 


waiver processing 


Waiver processing refers to processing that must be carried 
out when insurance premiums are waived because the insured 
has become disabled and the policy carried a disability rider. 
After a policy has gone into premium-waiver status, the 
premiums are in essence paid by the insurance company. If 
the insured does not remain disabled indefinitely, the policy 
may resume premium-paying status. 


waiver status (WAIV) 


Such a status indicates that premiums are no longer being paid 
by the policyholder because of a disability. The policy 
remains in force with the insurance company paying the 
premiums. 



Other modifications and variations to the embodiments described above can be 
made without departing from the spirit and scope of the invention, as is intended to be 
encompassed by the following claims and their legal equivalents. 
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